deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Date Mon, 18 Feb 2013 23:25:03 GMT
I think this received enough +1 votes (I'll add mine now) to proceed.  If a
Red Hatter (Marius?) would do the simplest repackaging possible and commit
that then others could join in the quest to modularize the hell out of it.
 :)  Presumably we'd do this on a branch until considered "baked" enough to
merge to master.

Let's go!

Matt


On Mon, Oct 15, 2012 at 10:55 AM, Arne Limburg <
arne.limburg@openknowledge.de> wrote:

> Hi,
>
> Some ideas from my side, too ([1] and [2]). Unfortunately it is in german.
> But everyone of you can read the code. We used an advanced version of that
> code to build a Spring-CDI-Bridge in a large project. Unfortunately
> meanwhile the project is completely migrated to CDI and the code is lost
> in subversion. Will see, if I find the final version and can donate it.
>
> Cheers,
> Arne
>
> [1]
> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe
> r-eine-cdi-extension-erster-teil.html
> [2]
> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-uebe
> r-eine-cdi-extension-zweiter-teil.html
>
>
> Am 15.10.12 17:16 schrieb "Jason Porter" unter <lightguard.jp@gmail.com>:
>
> >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-us
> >>age.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-us
> >>age.html#d0e92
> >> >>> [4]
> >> >>>
> >> >>
> >>
> >>
> http://docs.jboss.org/seam/3/spring/latest/reference/en-US/html/spring-us
> >>age.html#d0e92
> >> >>> [5]
> >> >>>
> >> >>
> >>
> >>
> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/BeanManag
> >>er.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