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 > >
