deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <arne.limb...@openknowledge.de>
Subject Re: [DISCUSS] Spring - CDI Integration in DeltaSpike
Date Mon, 15 Oct 2012 15:55:36 GMT
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
View raw message