Let me refine my plan to say that it would be *best* if Marius does the commit since AIUI this is mostly code he personally authored, but as long as RH intends for Seam-Spring to be donated to Apache deltaspike, probably no irreparable *harm* would be caused by another Red Hatter pulling the trigger.
Matt On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson <[email protected]> wrote: > I think this received enough +1 votes (I'll add mine now) to proceed. If > a Red Hatter (Marius?) would do the simplest repackaging possible and > commit that then others could join in the quest to modularize the hell out > of it. :) Presumably we'd do this on a branch until considered "baked" > enough to merge to master. > > Let's go! > > Matt > > > On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg < > [email protected]> wrote: > >> 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<http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-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<http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-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 >> >> >
