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, 18 Feb 2013 23:31:06 GMT
I'm pretty sure we've granted Seam Spring to Apache. I'll need to check to
see if Marius has subscribed to this list on a personal email as he has
embarked on a new adventure outside of Red Hat.


On Mon, Feb 18, 2013 at 4:27 PM, Matt Benson <gudnabrsam@gmail.com> wrote:

> Let me refine my plan to say that it would be *best* if Marius does the
> commit since AIUI this is mostly code he personally authored, but as long
> as RH intends for Seam-Spring to be donated to Apache deltaspike, probably
> no irreparable *harm* would be caused by another Red Hatter pulling the
> trigger.
>
> Matt
>
>
> On Mon, Feb 18, 2013 at 5:25 PM, Matt Benson <gudnabrsam@gmail.com> wrote:
>
> > 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<
> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-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<
> http://www.openknowledge.de/blog/article/integration-von-spring-in-cdi-ueber-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
> >>
> >>
> >
>



-- 
Jason Porter
http://en.gravatar.com/lightguardjp

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