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
