deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Date Mon, 15 Oct 2012 07:41:20 GMT
+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 <struberg@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.bogoevici@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
> >
>

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