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:50:19 GMT
Seems Marius's prior participation on this thread was via a gmail address.
 With him no longer at Red Hat we definitely want to make sure we take the
necessary precautions wrt IP.

Matt


On Mon, Feb 18, 2013 at 5:31 PM, Jason Porter <lightguard.jp@gmail.com>wrote:

> 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