deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Date Mon, 15 Oct 2012 15:16:23 GMT
You have my +1 Marius. If we can rouse the CDISource guys (mostly Rick)
they may have some ideas as well.

On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand <
antoine@sabot-durand.net> wrote:

> +1 it would definitively improve Java EE and CDI adoption.
>
> Antoine SABOT-DURAND
>
>
>
> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <rmannibucau@gmail.com> a
> écrit :
>
> > +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
> >>>
> >>
>
>


-- 
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu

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