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
