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