Sent from my iPhone
On 2012-10-15, at 3:35, Mark Struberg <strub...@yahoo.de> wrote: > 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? Yes, except that we would also support the case where the context is bootstrapped via a ContextLoaderListener, to allow easier integration with existing Spring MVC applications. > > 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. No, it would be disastrous. We wouldn't be able to support namespaces, JavaConfig and such, including auxiliary frameworks of the Spring portfolio. > 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-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 >>
