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 >
