deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marius Bogoevici <>
Subject [DISCUSS] Spring - CDI Integration in DeltaSpike
Date Mon, 15 Oct 2012 06:33:04 GMT
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


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 

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)


The integration can be split into multiple modules, one for each 
features above. a) can be split into two different modules too.


I think that the first vote would be for the inclusion of the module (or 
modules), followed by discussion of the JIRAs.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message