You have my +1 Marius. If we can rouse the CDISource guys (mostly Rick) they may have some ideas as well.
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
