Sorry about my previous remark. I was thinking that we would like to integrate the "Spring Integration" project. Confusion around the wording.
+1 to move into the direction to integrate Spring AND CDI. This was the motivation of my tweet of yesterday evening but not related to this thread ( https://twitter.com/cmoulliard/statuses/426105815683321856). On Thu, Jan 23, 2014 at 7:42 AM, Romain Manni-Bucau <[email protected]>wrote: > @Charles: ? don't get the point. You would like to use camel to bridge > spring and cdi? seems just overengineered and not efficient compared > to real integration + why doing a route, setuping camel context just > for it + you need then to use camel proxies to get a "normal" API > which is a lot to get nothing fancy and surely slow. > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014/1/23 Charles Moulliard <[email protected]>: > > -1. Why would you like to support Spring Integration while we have Apache > > Camel which is the most elaborated Spring Java Integration Framework > > available today, easier to setup, ... proposing also annotations > @Produce, > > @Consume to produce an exchange from and to a Camel Route (= list of > > processors) > > > > > > On Wed, Jan 22, 2014 at 7:36 PM, Jason Porter <[email protected] > >wrote: > > > >> +1 for adding the Spring integration > >> > >> > >> On Wed, Jan 22, 2014 at 11:21 AM, John D. Ament <[email protected] > >> >wrote: > >> > >> > +1 to Romain > >> > I'd like to see something like this for a 1.0 release. It would be a > >> > real game changer. > >> > > >> > On Wed, Jan 22, 2014 at 12:03 PM, Romain Manni-Bucau > >> > <[email protected]> wrote: > >> > > I'd release 0.6 before having it, it will surely create discussion > >> > > once we'll get something and it is easy to do something totally > >> > > brokenn in particular when we'll want to get something clever in a > web > >> > > context > >> > > > >> > > btw we shouldn't do it without pivotal IMO > >> > > Romain Manni-Bucau > >> > > Twitter: @rmannibucau > >> > > Blog: http://rmannibucau.wordpress.com/ > >> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> > > Github: https://github.com/rmannibucau > >> > > > >> > > > >> > > > >> > > 2014/1/22 Jason Porter <[email protected]>: > >> > >> Do we just want to take what we had in Seam 3 and move it over? > >> > >> > >> > >> > >> > >> On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek < > >> > >> [email protected]> wrote: > >> > >> > >> > >>> hi jason, > >> > >>> > >> > >>> the bridge doesn't introduce an api and the spi just provides a > >> simple > >> > >>> contract for starting the container as well as a bean-filter. > >> > >>> -> if needed, we could improve the implementation at any time. > >> > >>> imo we should add it before the release of v0.6 (since a lot of > users > >> > >>> requested such a bridge). > >> > >>> > >> > >>> regards, > >> > >>> gerhard > >> > >>> > >> > >>> > >> > >>> > >> > >>> 2014/1/22 Jason Porter <[email protected]> > >> > >>> > >> > >>> > I'd like to engage the Pivotal Team (anyone have contacts?) to > see > >> > if we > >> > >>> > can get some of there help as well to create a really good > >> > integration. > >> > >>> > > >> > >>> > > >> > >>> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek < > >> > >>> > [email protected]> wrote: > >> > >>> > > >> > >>> >> hi @ all, > >> > >>> >> > >> > >>> >> i would like to continue with this discussion. > >> > >>> >> > >> > >>> >> [1] describes a two-way bridge which is already based on > >> deltaspike. > >> > >>> >> it offers a simple spi which allows more advanced add-ons like > it > >> is > >> > >>> >> mentioned in [2]. > >> > >>> >> > >> > >>> >> regards, > >> > >>> >> gerhard > >> > >>> >> > >> > >>> >> [1] > >> > >>> >> > >> > >>> > >> > > >> > http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html > >> > >>> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html > >> > >>> >> > >> > >>> >> > >> > >>> >> > >> > >>> >> 2013/2/19 Matt Benson <[email protected]> > >> > >>> >> > >> > >>> >>> Okay, I spent some time with Sam on IRC hashing this out. > >> Assuming > >> > >>> that > >> > >>> >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for > >> > >>> deltaspike, > >> > >>> >>> his view is that it's not terribly important who does the > initial > >> > code > >> > >>> >>> import, though it would be best for a so-authorized Red > Hatter to > >> > be > >> > >>> the > >> > >>> >>> one to change the file headers. I will be out of pocket for > the > >> > rest > >> > >>> of > >> > >>> >>> the week beyond today, so if you, Marius, are able to work on > the > >> > >>> import > >> > >>> >>> end of this week/early next then that's in any event as soon > as I > >> > would > >> > >>> >>> have been able to get to it anyway. Otherwise, anyone can do > >> that, > >> > >>> with > >> > >>> >>> someone still employed by RH finally applying the change that > >> > modifies > >> > >>> >>> the > >> > >>> >>> headers--which, I suppose, could be prepared by anyone else > and > >> > simply > >> > >>> >>> shared among our private git repos. > >> > >>> >>> > >> > >>> >>> Matt > >> > >>> >>> > >> > >>> >>> > >> > >>> >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici < > >> > >>> >>> [email protected]> wrote: > >> > >>> >>> > >> > >>> >>> > 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 < > [email protected]> > >> > 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 < > >> > >>> >>> [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 > >> > >>> >>> > >> > >> > >>> >>> > > >> > >>> >>> > > >> > >>> >>> > >> > >>> >> > >> > >>> >> > >> > >>> > > >> > >>> > > >> > >>> > -- > >> > >>> > Jason Porter > >> > >>> > http://en.gravatar.com/lightguardjp > >> > >>> > > >> > >>> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> Jason Porter > >> > >> http://en.gravatar.com/lightguardjp > >> > > >> > >> > >> > >> -- > >> Jason Porter > >> http://en.gravatar.com/lightguardjp > >> > > > > > > > > -- > > Charles Moulliard > > Apache Committer / Architect @RedHat > > Twitter : @cmoulliard | Blog : http://cmoulliard.github.io > -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
