-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
