I still am a participant on this thread, but doing more reading than writing as of late :)
So, yes, I've been strapped for time with the job and the transition, but I'd be happy to help out with this at the end of the week or early next. With my CLA on file, and the code being granted already, I'm not sure what else needs to be done. I'm happy for the code to live in DeltaSpike, fwiw. On 2013-02-18, at 6:50 PM, Matt Benson <gudnabr...@gmail.com> wrote: > 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 <lightguard...@gmail.com>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 <gudnabr...@gmail.com> 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 <gudnabr...@gmail.com> >>> 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 < >>>> arne.limb...@openknowledge.de> 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 < >>> lightguard...@gmail.com>: >>>>> >>>>>> 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 < >>>>>> anto...@sabot-durand.net> wrote: >>>>>> >>>>>>> +1 it would definitively improve Java EE and CDI adoption. >>>>>>> >>>>>>> Antoine SABOT-DURAND >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <rmannibu...@gmail.com> >>> 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 <strub...@yahoo.de> >>>>>>>> >>>>>>>>> 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 <marius.bogoev...@gmail.com> >>>>>>>>>> To: deltaspike-dev@incubator.apache.org >>>>>>>>>> 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 >>
