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 > > >> > > > > >
