Hi Lenny,
On Wed, Aug 17, 2011 at 5:41 PM, Lenny Primak <lpri...@hope.nyc.ny.us>wrote:
> Can you create a github project for cdimodule? I would love to be a part
> of that.
>
I have not yet tried git - so this could be a good excuse for that :)
I'll look into that soon - would be cool to have other try and
possibly contribute as well!
> Regarding live class reloading, my solution to that was to use 'skinny' war
> files and put tapestry jars into domain/lib directory in glassfish. This
> makes redeploys Lightning fast and glassfish saves session state to boot.
> Not quite live reloading but it works well and also works for EJBs and web
> services that are within the app.
>
Great - I'll have to test that with my setup. Hopefully the turnaround will
be acceptable
>
> Do you think you can make an EJB annotation so I can test and contribute to
> your module easier? I have no 'plain' CDI beans to teat with nor do I have
> beans.xml.
>
The code for CDI annotationworker is simple.
*public class CDIAnnotationWorker implements ComponentClassTransformWorker {
*
* private CDIFactory cdiFactory;*
* public CDIAnnotationWorker(CDIFactory cdiFactory) {*
* this.cdiFactory = cdiFactory;*
* }*
* public void transform(ClassTransformation transformation,*
* MutableComponentModel model) {*
* for(final TransformField field :
transformation.matchFieldsWithAnnotation(CDI.class)) {*
* final CDI annotation = field.getAnnotation(CDI.class);*
* String fieldType = field.getType();*
* Class type = transformation.toClass(fieldType);*
* final Object injectionValue = cdiFactory.get(type);*
* *
* if(injectionValue!=null) {*
* field.inject(injectionValue);*
* field.claim(annotation);*
* }*
* } *
* }*
*}*
*
*
I'm sure you can adapt to support EJB by getting needed info from
annotation values and do the context lookup.
Perhaps use class/interface type as default jndi name so you don't need to
specify annotation values?
If no values are needed for ejb annotation, then an objectprovider could be
contributed to masterobjectprovider as well and you could use standard
@inject
Without knowing details I think you could possibly reuse
the JNDIObjectLocator from jumpstart for worker and/or masterobjectprovider.
*
*
*From CDIModule configuration*
*...*
@Contribute(ComponentClassTransformWorker.class)
public static void
provideClassTransformWorkers(OrderedConfiguration<ComponentClassTransformWorker>
configuration) {
configuration.addInstance("CDI", CDIAnnotationWorker.class,
"before:Property");
}
Hope that helps a bit. As I mentioned I'll try to get CDIModule up in github
soon...
--magnus
>
> Thanks!
>
> On Aug 17, 2011, at 11:08 AM, Magnus Kvalheim <mag...@kvalheim.dk> wrote:
>
> > I'm are still very interested in moving from tomcat to a EE6 server like
> > glassfish in order to adopt standards and benefit from the new stuff.
> >
> > Have not found time to actually replace spring with cdi in our apps.
> > There were also stuff we need to find a different solution for when
> moving
> > away from spring/tomcat to glassfish.
> >
> > Like:
> > * how to do opensessioninview (OSIV) pattern with ejb's (were currently
> > using spring here as well): (this looks promising though
> >
> http://ocpsoft.com/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/
> > )
> > * live reload with glassfish - not yet resolved
> > * some issues where debugging failed with glassfish/wtp plugin for
> eclipse
> > (possibly a jdk issue)
> >
> > I have today revisited the CDIModule I used for integration
> test/research.
> >
> > In order to address the 'issue' with Ordering of CDIProvider I attempted
> to
> > make a new annotation - @CDI.
> > The idea was that this would be used for injection instead of tapestry's
> > @inject.
> > I took - as you suggested - inspiration from @PersistenceContext in
> > tapestry-jpa.
> > This actually worked fine and is now injecting beans from cdi.
> >
> > Then I revisited the CDIProvider and its ordered contribution
> > to MasterObjectProvider.
> > Turns out it is indeed last in chain
> > - I have however no idea why it is asked to provide object for a defined
> > tapestry service though. *Is there something called after that is
> supposed
> > to resolve a service after all Objectproviders have been asked?*
> > If so - then how can I get CDIProvider to come after this?
> >
> > It is possible to specify exclusions in beans.xml (weld has extensions),
> but
> > I'd rather have it's just working out of the box.
> >
> >
> > So what I have implemented is:
> > * CDIProvider contributed to MasterObjectProvider - allows for cdi
> managed
> > beans to be injected with tapestry's @Inject
> > * @CDI annotation which can be used as alternative to @Inject. (An @EJB
> > annotation would have similar implementation). Using this annotation will
> > also sidestep the Objectprovider conendrum.
> >
> > I've tested beans with @ApplicationScoped and @RequestScoped and it works
> > great! Guess @ConversationScoped would work too - have got to test that
> > next :)
> >
> > Perhaps I should upload/host the CDIModule somewhere - seems like others
> can
> > benefit from it as well...
> >
> > --magnus
> >
> > On Wed, Aug 17, 2011 at 5:28 AM, Lenny Primak <lpri...@hope.nyc.ny.us
> >wrote:
> >
> >> I just took a look at that post, but it leaves a lot of unanswered
> >> questions,
> >> actually more questions than answers.
> >>
> >> I know tapestry-jpa made @PersistenceContext work within Tapestry,
> >> which is similar. I am going to look at that.
> >> Perhaps Igor can shed some light on this.
> >>
> >> Thanks again.
> >>
> >> On Aug 14, 2011, at 8:10 AM, Thiago H. de Paula Figueiredo wrote:
> >>
> >>> On Sat, 13 Aug 2011 15:37:43 -0300, Lenny Primak <
> lpri...@hope.nyc.ny.us>
> >> wrote:
> >>>
> >>>> Hi guys,
> >>>
> >>> Hi!
> >>>
> >>>> I am developing a front-end in Tapestry for an EJB application (EJB
> >> 3.1/JEE 6) Its getting really annoying to build Tapestry services for
> each
> >> of the EJBs. Do you have any suggestions on how to support @EJB
> annotation
> >> instead?
> >>>
> >>> Magnus did something this, but for CDI, and posted in this mailing
> list:
> >>
> http://tapestry.1045711.n5.nabble.com/First-stab-at-CDI-module-for-tapestry-td4469281.html
> .
> >> I haven't used CDI nor EJB, so I don't know if its solution can be used
> for
> >> EJB without any changes. Even if not, the approach would be very
> similar.
> >>>
> >>> --
> >>> Thiago H. de Paula Figueiredo
> >>> Independent Java, Apache Tapestry 5 and Hibernate consultant,
> developer,
> >> and instructor
> >>> Owner, Ars Machina Tecnologia da Informação Ltda.
> >>> http://www.arsmachina.com.br
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >> For additional commands, e-mail: users-h...@tapestry.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
