On Wed, Aug 17, 2011 at 6:12 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote:
> On Wed, 17 Aug 2011 12:08:12 -0300, 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. >> > > Why not EJB 3.1's embedded mode? This way, you can run EJB like a package > instead as a container. At least OpenEJB supports that. > Yes sure, if that's feasible. I was attracted to glassfish as it's battle tested, with great features and tooling, but it's worth having a look at other options like OpenEJB. Thanks I'll check it out :) > 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. >> > > Why not javax.injection.@Inject from JSR 330? Tapestry already supports > that: http://tapestry.apache.org/**using-jsr-330-standard-** > annotations.html<http://tapestry.apache.org/using-jsr-330-standard-annotations.html> > and http://blog.tapestry5.de/**index.php/2011/01/17/javax-** > inject-inject-support-in-**tapestry/<http://blog.tapestry5.de/index.php/2011/01/17/javax-inject-inject-support-in-tapestry/> Aren't those interchangeable so that it will work same as tapestry's @inject? wouldn't that conflict with tapestry 5.3? @CDI annotation is the alternative that don't go though the masterobjectprovider for providing injection. > > - 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?* >> > > I'm not sure, but I guess that's exactly how Tapestry-IoC deals with > ObjectProviders. > hmm.. so perhaps I need to do it some other way. I'll debug and look closer to whats actually going on when resolving dependencies and see if I can find a better solution. Please let me know if anyone has suggestions :) > -- > 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 > On Wed, Aug 17, 2011 at 9:45 PM, Magnus Kvalheim <mag...@kvalheim.dk> wrote: > 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 >> >> >
