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
