Seems Marius's prior participation on this thread was via a gmail address. With him no longer at Red Hat we definitely want to make sure we take the necessary precautions wrt IP.
Matt On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter <[email protected]>wrote: > I'm pretty sure we've granted Seam Spring to Apache. I'll need to check to > see if Marius has subscribed to this list on a personal email as he has > embarked on a new adventure outside of Red Hat. > > > On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson <[email protected]> wrote: > >> 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 >> >> >> >> >> > >> > > > > -- > Jason Porter > http://en.gravatar.com/lightguardjp >
