+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
