+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-usage.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-usage.html#d0e92 > > [4] > > > http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-usage.html#d0e92 > > [5] > > > http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/BeanManager.html > > >
