@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 <ch0...@gmail.com>: > -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 <lightguard...@gmail.com>wrote: > >> +1 for adding the Spring integration >> >> >> On Wed, Jan 22, 2014 at 11:21 AM, John D. Ament <john.d.am...@gmail.com >> >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 >> > <rmannibu...@gmail.com> 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 <lightguard...@gmail.com>: >> > >> 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 < >> > >> gerhard.petra...@gmail.com> 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 <lightguard...@gmail.com> >> > >>> >> > >>> > 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 < >> > >>> > gerhard.petra...@gmail.com> 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 <gudnabr...@gmail.com> >> > >>> >> >> > >>> >>> 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 < >> > >>> >>> marius.bogoev...@gmail.com> 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 <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-...@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 >> > >>> >>> > >> >> > >>> >>> > >> > >>> >>> > >> > >>> >>> >> > >>> >> >> > >>> >> >> > >>> > >> > >>> > >> > >>> > -- >> > >>> > 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
