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 >
