On Tue, May 29, 2012 at 2:06 PM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote:
> On Tue, 29 May 2012 07:47:12 -0300, Magnus Kvalheim <mag...@kvalheim.dk> > wrote: > > [2]CDI support >> With Jee6 it's highly desirable to use cdi(jsr 299) for managing beans. I >> dare to say in most cases spring can be avoided completely and what you >> get is a app(s) with far less dependencies and configuration. >> To top it off you even get conversational scope for free! >> The module - >> https://github.com/**magnuskvalheim/tapestry-cdi<https://github.com/magnuskvalheim/tapestry-cdi>- >> could be used as initial codebase for tapestry cdi. >> > > Something I was thinking about Tapestry-IoC with CDI was the possibility > of configuring all services in Tapestry-IoC and then somehow pass them to > CDI, so CDI could handle transactions and stuff like that. We could also > provide injections from T-IoC to CDI. In this scenario, I was thinking of > having a different TapestryFilter implementation that sets a Registry > instance in the ServletContext that pulls services from CDI (T-IoC > indirectly) and not directly from T-IoC. This way, we can have the best of > both worlds (transactions and other stuff from CDI and the nice features of > T-IoC like distributed configuration, easy decoration of services, etc). We > probably would need > *Bootstrap* cdi (weld) is normally triggered on the existence of beans.xml in web/meta-inf. Once started a beanmanager will be registered in jndi and available through context. In the current implementation of tapestry-cdi (among other things) a custom injectionprovider is registered. It looks up and injects cdi beans on @Inject. *T-IoC to CDI* It is quite possible to wrap and feed tapestry services to CDI. This is done by making a portable extension. http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html_single/#extend *Transactions* CDI don't offer transactions yet. Although I think it's on the roadmap I believe it's recommended to use ejb's. (Maybe a little too much detail, but guess it's possible to use interceptors which work much the same way as a tapestry ComponentClassTransformWorker, http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html_single/#interceptors ) > > What do you think? I have no CDI experience, so I'm not sure what I'm > describing above is feasible. And this idea would be an option to what > you've done in tapestry-cdi, so people can choose what CDI integration they > want. I'm still learning cdi as well, but from what I know I think it's best to let cdi bootstap normally and then inject in tapestry through injectionprovider - and contribute t-services to cdi through a portable extension. Perhaps others have some more input though... > > > -- > Thiago >
