The biggest advantage of using glassfish is that everything is pre-configured for you, you don't need to deal with any dependencies, no putting stuff together yourself, it 'just works' and y you get everything - Tapestry, REST, WebServices, EJB, the whole stack with zero effort.
On Aug 17, 2011, at 4:20 PM, Magnus Kvalheim wrote: > 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 >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
