Thanks Arne, that looks useful! :) (I can read German ;))
Sent from my iPhone On 2012-10-15, at 11:55, 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 > [2] > http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe > r-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-dev@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 >
