Sent from my iPhone
On 2012-10-15, at 11:16, Jason Porter <[email protected]> wrote: > You have my +1 Marius. If we can rouse the CDISource guys (mostly Rick) > they may have some ideas as well. I talked to Rick at Java One and he said that he'll try. > > On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand < > [email protected]> wrote: > >> +1 it would definitively improve Java EE and CDI adoption. >> >> Antoine SABOT-DURAND >> >> >> >> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[email protected]> a >> écrit : >> >>> +1 (since DS manages spring context lifecycle) >>> >>> *Romain Manni-Bucau* >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>> *Blog: **http://rmannibucau.wordpress.com/*< >> http://rmannibucau.wordpress.com/> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>> *Github: https://github.com/rmannibucau* >>> >>> >>> >>> >>> 2012/10/15 Mark Struberg <[email protected]> >>> >>>> great stuff, +1! >>>> >>>> Just to help me understand a bit better. This module will cover a >>>> Spring-CDI bridge, so you boot Spring and a CDI container and route the >>>> beans between both of them, right? >>>> >>>> Just for getting the whole picture: Another way is to just interpret the >>>> spring beans.xml and serve it all purely with CDI. Of course this will >>>> pretty surely not be possible to implement 100% compatible thus I'm not >>>> sure if it's worth implementing at all. >>>> I guess this is _not_ covered in your proposal, right? Imo this is >>>> perfectly fine, I just mention it for clarity. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: Marius Bogoevici <[email protected]> >>>>> To: [email protected] >>>>> Cc: >>>>> Sent: Monday, October 15, 2012 8:33 AM >>>>> Subject: [DISCUSS] Spring - CDI Integration in DeltaSpike >>>>> >>>>> Hello all, >>>>> >>>>> Please check [1] before you answer. >>>>> >>>>> I'd like to propose the addition of a new module for integrating Spring >>>> with >>>>> CDI. We have discussed this on the e-mail list but let me provide a >> quick >>>>> rationale for it. >>>>> >>>>> - it eases adoption of CDI and, by extension, Java EE, in environments >>>> with a >>>>> significant existing Spring codebase; >>>>> - it provides a general solution for Spring/Java EE integration; >>>>> - it provides users with more options in choosing the best components >>>> for their >>>>> application, knowing that they are not locked in either of the >> paradigms >>>> (e.g. a >>>>> user can integrate a project with a strong CDI-based programming API >> with >>>>> something like Spring Batch or Spring Integration); >>>>> >>>>> Features (proposed) >>>>> ----------------- >>>>> >>>>> a) bidirectional injection of beans (Spring into CDI and vice-versa); >>>>> b) bridging EntityTransaction support between DeltaSpike and Spring; >>>>> c) integrating the CDI event model with Spring (the best approach in my >>>> opinion >>>>> being Spring Integraton rather than the core) >>>>> d) integration with other Spring portfolio projects wherever possible; >>>>> >>>>> For version 0.4 a minimal goal would be a), followed by b) if possible. >>>>> >>>>> General approach (covers a)) >>>>> ================= >>>>> >>>>> For 0.4. my intent, by and large, is to follow the approaches of the >>>> Seam 3 >>>>> Spring module (including a code migration), making improvements on its >>>> design >>>>> wherever possible. I intend to create individual JIRAs for a more >>>> detailed >>>>> discussion, but here's the outline: >>>>> >>>>> The general principle is that each side (Spring, CDI) should not know >>>> about the >>>>> existence of the other. Spring beans should be used as CDI beans >>>> transparently >>>>> and vice-versa. >>>>> >>>>> So where do beans come from? >>>>> ------------------------ >>>>> >>>>> Spring beans are exposed through a /resource producer pattern//./ >>>>> >>>>> @Produces @SpringBean Foo bar; >>>>> >>>>> Will produce a CDI bean of the type Foo acquired from the Spring >> context >>>>> >>>>> Details: >> http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-usage.html#d0e92 >>>>> >>>>> What Spring context? >>>>> ------------------ >>>>> >>>>> For flexibility reasons, we do not assume where the Spring context is >>>> coming >>>>> from. Therefore, we allow different mechanisms for accessing a Spring >>>> context. >>>>> In fact, multiple contexts can be used for import. >>>>> >>>>> a) parent web context [3] >>>>> >>>>> @Produces @Web @SpringContext ApplicationContext applicationContext; >>>>> >>>>> b) Configuration-file based application context [4] >>>>> >>>>> @Produces @Configuration("classpath*:META-INF/spring/context.xml") >>>>> @SpringContext ApplicationContext applicationContext; >>>>> >>>>> (TBD: issues like auto-import and auto-vetoing, as well as sensible >>>> defaults) >>>>> >>>>> The Spring bean producer can reference a specific context (see >>>> documentation for >>>>> details) >>>>> >>>>> Note: When we get to the JIRAs we can consider alternative designs - >> e.g. >>>>> grouping all producers for a particular context in a single bean and >>>> making that >>>>> bean the Spring context reference marker. >>>>> >>>>> Note #2: In regards to the CDISource implementation: I am happy with >>>> reusing >>>>> some of the stuff there, but I have a hard time looking at the code, >> it's >>>>> never been released (as in a Maven release), lacks documentation, and >>>> reverse >>>>> engineering is hard. So if someone that is familiar with the code and >>>> finds >>>>> something particularly apt for reuse, and it's also OK from an Apache >>>> code >>>>> policy point of view, we should incorporate anything that helps. What >> I >>>> am not >>>>> particularly happy with is the approach of annotating CDI injection >>>> points with >>>>> the @Spring marker, which I believe violates separation of concerns - I >>>> consider >>>>> production or auto-registration a better approach (CDI targets should >>>> not know >>>>> about the provenience of the bean). >>>>> >>>>> >>>>> CDI into Spring integration [5] >>>>> =================== >>>>> >>>>> Conversely, CDI beans can be injected into Spring applications. To that >>>> end, we >>>>> will provide a namespace (and possibly a JavaConfig configuration >>>> mechanism) >>>>> >>>>> Structure >>>>> ====== >>>>> >>>>> The integration can be split into multiple modules, one for each >>>> features above. >>>>> a) can be split into two different modules too. >>>>> >>>>> Roadmap >>>>> ====== >>>>> >>>>> I think that the first vote would be for the inclusion of the module >> (or >>>>> modules), followed by discussion of the JIRAs. >>>>> >>>>> >>>>> >>>>> [1] http://markmail.org/message/7yefspfuvtz4jvmp >>>>> [2] https://cwiki.apache.org/DeltaSpike/spring-cdi-integration.html >>>>> [3] >> http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-usage.html#d0e92 >>>>> [4] >> http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-usage.html#d0e92 >>>>> [5] >> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/BeanManager.html > > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > Author of Seam Catch - Next Generation Java Exception Handling > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu
