Hi, Some ideas from my side, too ([1] and [2]). Unfortunately it is in german. But everyone of you can read the code. We used an advanced version of that code to build a Spring-CDI-Bridge in a large project. Unfortunately meanwhile the project is completely migrated to CDI and the code is lost in subversion. Will see, if I find the final version and can donate it.
Cheers, Arne [1] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-erster-teil.html [2] http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe r-eine-cdi-extension-zweiter-teil.html Am 15.10.12 17:16 schrieb "Jason Porter" unter <[email protected]>: >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-us >>age.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-us >>age.html#d0e92 >> >>> [4] >> >>> >> >> >> >>http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-us >>age.html#d0e92 >> >>> [5] >> >>> >> >> >> >>http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/BeanManag >>er.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
