[DISCUSS] Spring - CDI Integration in DeltaSpike

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Spring - CDI Integration in DeltaSpike

Marius Bogoevici
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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Mark Struberg
Administrator
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 <[hidden email]>
> To: [hidden email]
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Romain Manni-Bucau
+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 <[hidden email]>

> 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 <[hidden email]>
> > To: [hidden email]
> > 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Antoine Sabot-Durand
+1 it would definitively improve Java EE and CDI adoption.

Antoine SABOT-DURAND



Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
>
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Jason Porter
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 <
[hidden email]> wrote:

> +1 it would definitively improve Java EE and CDI adoption.
>
> Antoine SABOT-DURAND
>
>
>
> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
> >
> >> 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 <[hidden email]>
> >>> To: [hidden email]
> >>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Arne Limburg
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 <[hidden email]>:

>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 <
>[hidden email]> wrote:
>
>> +1 it would definitively improve Java EE and CDI adoption.
>>
>> Antoine SABOT-DURAND
>>
>>
>>
>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
>> >
>> >> 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 <[hidden email]>
>> >>> To: [hidden email]
>> >>> 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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Marius Bogoevici
In reply to this post by Mark Struberg


Sent from my iPhone

On 2012-10-15, at 3:35, Mark Struberg <[hidden email]> wrote:

> 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?

Yes, except that we would also support the case where the context is bootstrapped via a ContextLoaderListener, to allow easier integration with existing Spring MVC applications.
>
> 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.

No, it would be disastrous. We wouldn't be able to support namespaces, JavaConfig and such, including auxiliary frameworks of the Spring portfolio.

> 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 <[hidden email]>
>> To: [hidden email]
>> 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
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Marius Bogoevici
In reply to this post by Jason Porter


Sent from my iPhone

On 2012-10-15, at 11:16, Jason Porter <[hidden email]> wrote:

> You have my +1 Marius. If we can rouse the CDISource guys (mostly Rick)
> they may have some ideas as well.

I talked to Rick at Java One and he said that he'll try.

>
> On Mon, Oct 15, 2012 at 1:53 AM, Antoine Sabot-Durand <
> [hidden email]> wrote:
>
>> +1 it would definitively improve Java EE and CDI adoption.
>>
>> Antoine SABOT-DURAND
>>
>>
>>
>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
>>>
>>>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Marius Bogoevici
In reply to this post by Arne Limburg
Thanks Arne, that looks useful! :)

(I can read German ;))

Sent from my iPhone

On 2012-10-15, at 11:55, Arne Limburg <[hidden email]> 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 <[hidden email]>:
>
>> 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 <
>> [hidden email]> wrote:
>>
>>> +1 it would definitively improve Java EE and CDI adoption.
>>>
>>> Antoine SABOT-DURAND
>>>
>>>
>>>
>>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
>>>>
>>>>> 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 <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Matt Benson
In reply to this post by Arne Limburg
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 <
[hidden email]> 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 <[hidden email]>:
>
> >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 <
> >[hidden email]> wrote:
> >
> >> +1 it would definitively improve Java EE and CDI adoption.
> >>
> >> Antoine SABOT-DURAND
> >>
> >>
> >>
> >> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
> >> >
> >> >> 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 <[hidden email]>
> >> >>> To: [hidden email]
> >> >>> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Matt Benson
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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]>:
>>
>> >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 <
>> >[hidden email]> wrote:
>> >
>> >> +1 it would definitively improve Java EE and CDI adoption.
>> >>
>> >> Antoine SABOT-DURAND
>> >>
>> >>
>> >>
>> >> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]>
>> >> >
>> >> >> 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 <[hidden email]>
>> >> >>> To: [hidden email]
>> >> >>> 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
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Jason Porter
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 <[hidden email]> 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 <[hidden email]> 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 <
> > [hidden email]> 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 <[hidden email]
> >:
> >>
> >> >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 <
> >> >[hidden email]> wrote:
> >> >
> >> >> +1 it would definitively improve Java EE and CDI adoption.
> >> >>
> >> >> Antoine SABOT-DURAND
> >> >>
> >> >>
> >> >>
> >> >> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[hidden email]>
> 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 <[hidden email]>
> >> >> >
> >> >> >> 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 <[hidden email]>
> >> >> >>> To: [hidden email]
> >> >> >>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Matt Benson
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 <[hidden email]>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 <[hidden email]> 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 <[hidden email]>
>> 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 <
>> > [hidden email]> 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 <
>> [hidden email]>:
>> >>
>> >> >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 <
>> >> >[hidden email]> wrote:
>> >> >
>> >> >> +1 it would definitively improve Java EE and CDI adoption.
>> >> >>
>> >> >> Antoine SABOT-DURAND
>> >> >>
>> >> >>
>> >> >>
>> >> >> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[hidden email]>
>> 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 <[hidden email]>
>> >> >> >
>> >> >> >> 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 <[hidden email]>
>> >> >> >>> To: [hidden email]
>> >> >> >>> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Marius Bogoevici
I still am a participant on this thread, but doing more reading than writing as of late :)

So, yes, I've been strapped for time with the job and the transition, but I'd be happy to help out with this at the end of the week or early next.

With my CLA on file, and the code being granted already, I'm not sure what else needs to be done. I'm happy for the code to live in DeltaSpike, fwiw.

On 2013-02-18, at 6:50 PM, Matt Benson <[hidden email]> wrote:

> 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 <[hidden email]>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 <[hidden email]> 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 <[hidden email]>
>>> 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 <
>>>> [hidden email]> 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 <
>>> [hidden email]>:
>>>>>
>>>>>> 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 <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> +1 it would definitively improve Java EE and CDI adoption.
>>>>>>>
>>>>>>> Antoine SABOT-DURAND
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[hidden email]>
>>> 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 <[hidden email]>
>>>>>>>>
>>>>>>>>> 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 <[hidden email]>
>>>>>>>>>> To: [hidden email]
>>>>>>>>>> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Matt Benson
Okay, I spent some time with Sam on IRC hashing this out.  Assuming that
Seam-Spring is covered under the SG(s?) Red Hat has filed for deltaspike,
his view is that it's not terribly important who does the initial code
import, though it would be best for a so-authorized Red Hatter to be the
one to change the file headers.  I will be out of pocket for the rest of
the week beyond today, so if you, Marius, are able to work on the import
end of this week/early next then that's in any event as soon as I would
have been able to get to it anyway.  Otherwise, anyone can do that, with
someone still employed by RH finally applying the change that modifies the
headers--which, I suppose, could be prepared by anyone else and simply
shared among our private git repos.

Matt


On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici <
[hidden email]> wrote:

> I still am a participant on this thread, but doing more reading than
> writing as of late :)
>
> So, yes, I've been strapped for time with the job and the transition, but
> I'd be happy to help out with this at the end of the week or early next.
>
> With my CLA on file, and the code being granted already, I'm not sure what
> else needs to be done. I'm happy for the code to live in DeltaSpike, fwiw.
>
> On 2013-02-18, at 6:50 PM, Matt Benson <[hidden email]> wrote:
>
> > 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 <[hidden email]
> >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 <[hidden email]>
> 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 <[hidden email]>
> >>> 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 <
> >>>> [hidden email]> 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 <
> >>> [hidden email]>:
> >>>>>
> >>>>>> 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 <
> >>>>>> [hidden email]> wrote:
> >>>>>>
> >>>>>>> +1 it would definitively improve Java EE and CDI adoption.
> >>>>>>>
> >>>>>>> Antoine SABOT-DURAND
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <[hidden email]
> >
> >>> 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 <[hidden email]>
> >>>>>>>>
> >>>>>>>>> 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 <[hidden email]>
> >>>>>>>>>> To: [hidden email]
> >>>>>>>>>> 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
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Gerhard Petracek
Administrator
hi @ all,

i would like to continue with this discussion.

[1] describes a two-way bridge which is already based on deltaspike.
it offers a simple spi which allows more advanced add-ons like it is
mentioned in [2].

regards,
gerhard

[1]
http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html
[2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html



2013/2/19 Matt Benson <[hidden email]>

> Okay, I spent some time with Sam on IRC hashing this out.  Assuming that
> Seam-Spring is covered under the SG(s?) Red Hat has filed for deltaspike,
> his view is that it's not terribly important who does the initial code
> import, though it would be best for a so-authorized Red Hatter to be the
> one to change the file headers.  I will be out of pocket for the rest of
> the week beyond today, so if you, Marius, are able to work on the import
> end of this week/early next then that's in any event as soon as I would
> have been able to get to it anyway.  Otherwise, anyone can do that, with
> someone still employed by RH finally applying the change that modifies the
> headers--which, I suppose, could be prepared by anyone else and simply
> shared among our private git repos.
>
> Matt
>
>
> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici <
> [hidden email]> wrote:
>
> > I still am a participant on this thread, but doing more reading than
> > writing as of late :)
> >
> > So, yes, I've been strapped for time with the job and the transition, but
> > I'd be happy to help out with this at the end of the week or early next.
> >
> > With my CLA on file, and the code being granted already, I'm not sure
> what
> > else needs to be done. I'm happy for the code to live in DeltaSpike,
> fwiw.
> >
> > On 2013-02-18, at 6:50 PM, Matt Benson <[hidden email]> wrote:
> >
> > > 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 <[hidden email]
> > >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 <[hidden email]>
> > 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 <[hidden email]>
> > >>> 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 <
> > >>>> [hidden email]> 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 <
> > >>> [hidden email]>:
> > >>>>>
> > >>>>>> 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 <
> > >>>>>> [hidden email]> wrote:
> > >>>>>>
> > >>>>>>> +1 it would definitively improve Java EE and CDI adoption.
> > >>>>>>>
> > >>>>>>> Antoine SABOT-DURAND
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <
> [hidden email]
> > >
> > >>> 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 <[hidden email]>
> > >>>>>>>>
> > >>>>>>>>> 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 <[hidden email]>
> > >>>>>>>>>> To: [hidden email]
> > >>>>>>>>>> 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
> > >>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Jason Porter
I'd like to engage the Pivotal Team (anyone have contacts?) to see if we
can get some of there help as well to create a really good integration.


On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek <
[hidden email]> wrote:

> hi @ all,
>
> i would like to continue with this discussion.
>
> [1] describes a two-way bridge which is already based on deltaspike.
> it offers a simple spi which allows more advanced add-ons like it is
> mentioned in [2].
>
> regards,
> gerhard
>
> [1]
> http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html
> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html
>
>
>
> 2013/2/19 Matt Benson <[hidden email]>
>
>> Okay, I spent some time with Sam on IRC hashing this out.  Assuming that
>> Seam-Spring is covered under the SG(s?) Red Hat has filed for deltaspike,
>> his view is that it's not terribly important who does the initial code
>> import, though it would be best for a so-authorized Red Hatter to be the
>> one to change the file headers.  I will be out of pocket for the rest of
>> the week beyond today, so if you, Marius, are able to work on the import
>> end of this week/early next then that's in any event as soon as I would
>> have been able to get to it anyway.  Otherwise, anyone can do that, with
>> someone still employed by RH finally applying the change that modifies the
>> headers--which, I suppose, could be prepared by anyone else and simply
>> shared among our private git repos.
>>
>> Matt
>>
>>
>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici <
>> [hidden email]> wrote:
>>
>> > I still am a participant on this thread, but doing more reading than
>> > writing as of late :)
>> >
>> > So, yes, I've been strapped for time with the job and the transition,
>> but
>> > I'd be happy to help out with this at the end of the week or early next.
>> >
>> > With my CLA on file, and the code being granted already, I'm not sure
>> what
>> > else needs to be done. I'm happy for the code to live in DeltaSpike,
>> fwiw.
>> >
>> > On 2013-02-18, at 6:50 PM, Matt Benson <[hidden email]> wrote:
>> >
>> > > 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 <
>> [hidden email]
>> > >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 <[hidden email]>
>> > 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 <[hidden email]>
>> > >>> 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 <
>> > >>>> [hidden email]> 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 <
>> > >>> [hidden email]>:
>> > >>>>>
>> > >>>>>> 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 <
>> > >>>>>> [hidden email]> wrote:
>> > >>>>>>
>> > >>>>>>> +1 it would definitively improve Java EE and CDI adoption.
>> > >>>>>>>
>> > >>>>>>> Antoine SABOT-DURAND
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <
>> [hidden email]
>> > >
>> > >>> 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 <[hidden email]>
>> > >>>>>>>>
>> > >>>>>>>>> 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 <[hidden email]>
>> > >>>>>>>>>> To: [hidden email]
>> > >>>>>>>>>> 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
>> > >>
>> >
>> >
>>
>
>


--
Jason Porter
http://en.gravatar.com/lightguardjp
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Gerhard Petracek
Administrator
hi jason,

the bridge doesn't introduce an api and the spi just provides a simple
contract for starting the container as well as a bean-filter.
-> if needed, we could improve the implementation at any time.
imo we should add it before the release of v0.6 (since a lot of users
requested such a bridge).

regards,
gerhard



2014/1/22 Jason Porter <[hidden email]>

> I'd like to engage the Pivotal Team (anyone have contacts?) to see if we
> can get some of there help as well to create a really good integration.
>
>
> On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek <
> [hidden email]> wrote:
>
>> hi @ all,
>>
>> i would like to continue with this discussion.
>>
>> [1] describes a two-way bridge which is already based on deltaspike.
>> it offers a simple spi which allows more advanced add-ons like it is
>> mentioned in [2].
>>
>> regards,
>> gerhard
>>
>> [1]
>> http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html
>> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html
>>
>>
>>
>> 2013/2/19 Matt Benson <[hidden email]>
>>
>>> Okay, I spent some time with Sam on IRC hashing this out.  Assuming that
>>> Seam-Spring is covered under the SG(s?) Red Hat has filed for deltaspike,
>>> his view is that it's not terribly important who does the initial code
>>> import, though it would be best for a so-authorized Red Hatter to be the
>>> one to change the file headers.  I will be out of pocket for the rest of
>>> the week beyond today, so if you, Marius, are able to work on the import
>>> end of this week/early next then that's in any event as soon as I would
>>> have been able to get to it anyway.  Otherwise, anyone can do that, with
>>> someone still employed by RH finally applying the change that modifies
>>> the
>>> headers--which, I suppose, could be prepared by anyone else and simply
>>> shared among our private git repos.
>>>
>>> Matt
>>>
>>>
>>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici <
>>> [hidden email]> wrote:
>>>
>>> > I still am a participant on this thread, but doing more reading than
>>> > writing as of late :)
>>> >
>>> > So, yes, I've been strapped for time with the job and the transition,
>>> but
>>> > I'd be happy to help out with this at the end of the week or early
>>> next.
>>> >
>>> > With my CLA on file, and the code being granted already, I'm not sure
>>> what
>>> > else needs to be done. I'm happy for the code to live in DeltaSpike,
>>> fwiw.
>>> >
>>> > On 2013-02-18, at 6:50 PM, Matt Benson <[hidden email]> wrote:
>>> >
>>> > > 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 <
>>> [hidden email]
>>> > >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 <[hidden email]>
>>> > 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 <[hidden email]
>>> >
>>> > >>> 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 <
>>> > >>>> [hidden email]> 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 <
>>> > >>> [hidden email]>:
>>> > >>>>>
>>> > >>>>>> 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 <
>>> > >>>>>> [hidden email]> wrote:
>>> > >>>>>>
>>> > >>>>>>> +1 it would definitively improve Java EE and CDI adoption.
>>> > >>>>>>>
>>> > >>>>>>> Antoine SABOT-DURAND
>>> > >>>>>>>
>>> > >>>>>>>
>>> > >>>>>>>
>>> > >>>>>>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <
>>> [hidden email]
>>> > >
>>> > >>> 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 <[hidden email]>
>>> > >>>>>>>>
>>> > >>>>>>>>> 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 <[hidden email]>
>>> > >>>>>>>>>> To: [hidden email]
>>> > >>>>>>>>>> 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
>>> > >>
>>> >
>>> >
>>>
>>
>>
>
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Jason Porter
Do we just want to take what we had in Seam 3 and move it over?


On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek <
[hidden email]> wrote:

> hi jason,
>
> the bridge doesn't introduce an api and the spi just provides a simple
> contract for starting the container as well as a bean-filter.
> -> if needed, we could improve the implementation at any time.
> imo we should add it before the release of v0.6 (since a lot of users
> requested such a bridge).
>
> regards,
> gerhard
>
>
>
> 2014/1/22 Jason Porter <[hidden email]>
>
> > I'd like to engage the Pivotal Team (anyone have contacts?) to see if we
> > can get some of there help as well to create a really good integration.
> >
> >
> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek <
> > [hidden email]> wrote:
> >
> >> hi @ all,
> >>
> >> i would like to continue with this discussion.
> >>
> >> [1] describes a two-way bridge which is already based on deltaspike.
> >> it offers a simple spi which allows more advanced add-ons like it is
> >> mentioned in [2].
> >>
> >> regards,
> >> gerhard
> >>
> >> [1]
> >>
> http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html
> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html
> >>
> >>
> >>
> >> 2013/2/19 Matt Benson <[hidden email]>
> >>
> >>> Okay, I spent some time with Sam on IRC hashing this out.  Assuming
> that
> >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for
> deltaspike,
> >>> his view is that it's not terribly important who does the initial code
> >>> import, though it would be best for a so-authorized Red Hatter to be
> the
> >>> one to change the file headers.  I will be out of pocket for the rest
> of
> >>> the week beyond today, so if you, Marius, are able to work on the
> import
> >>> end of this week/early next then that's in any event as soon as I would
> >>> have been able to get to it anyway.  Otherwise, anyone can do that,
> with
> >>> someone still employed by RH finally applying the change that modifies
> >>> the
> >>> headers--which, I suppose, could be prepared by anyone else and simply
> >>> shared among our private git repos.
> >>>
> >>> Matt
> >>>
> >>>
> >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici <
> >>> [hidden email]> wrote:
> >>>
> >>> > I still am a participant on this thread, but doing more reading than
> >>> > writing as of late :)
> >>> >
> >>> > So, yes, I've been strapped for time with the job and the transition,
> >>> but
> >>> > I'd be happy to help out with this at the end of the week or early
> >>> next.
> >>> >
> >>> > With my CLA on file, and the code being granted already, I'm not sure
> >>> what
> >>> > else needs to be done. I'm happy for the code to live in DeltaSpike,
> >>> fwiw.
> >>> >
> >>> > On 2013-02-18, at 6:50 PM, Matt Benson <[hidden email]> wrote:
> >>> >
> >>> > > 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 <
> >>> [hidden email]
> >>> > >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 <
> [hidden email]>
> >>> > 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 <
> [hidden email]
> >>> >
> >>> > >>> 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 <
> >>> > >>>> [hidden email]> 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 <
> >>> > >>> [hidden email]>:
> >>> > >>>>>
> >>> > >>>>>> 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 <
> >>> > >>>>>> [hidden email]> wrote:
> >>> > >>>>>>
> >>> > >>>>>>> +1 it would definitively improve Java EE and CDI adoption.
> >>> > >>>>>>>
> >>> > >>>>>>> Antoine SABOT-DURAND
> >>> > >>>>>>>
> >>> > >>>>>>>
> >>> > >>>>>>>
> >>> > >>>>>>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <
> >>> [hidden email]
> >>> > >
> >>> > >>> 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 <[hidden email]>
> >>> > >>>>>>>>
> >>> > >>>>>>>>> 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 <[hidden email]>
> >>> > >>>>>>>>>> To: [hidden email]
> >>> > >>>>>>>>>> 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
> >>> > >>
> >>> >
> >>> >
> >>>
> >>
> >>
> >
> >
> > --
> > Jason Porter
> > http://en.gravatar.com/lightguardjp
> >
>



--
Jason Porter
http://en.gravatar.com/lightguardjp
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Spring - CDI Integration in DeltaSpike

Romain Manni-Bucau
I'd release 0.6 before having it, it will surely create discussion
once we'll get something and it is easy to do something totally
brokenn in particular when we'll want to get something clever in a web
context

btw we shouldn't do it without pivotal IMO
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014/1/22 Jason Porter <[hidden email]>:

> Do we just want to take what we had in Seam 3 and move it over?
>
>
> On Wed, Jan 22, 2014 at 9:51 AM, Gerhard Petracek <
> [hidden email]> wrote:
>
>> hi jason,
>>
>> the bridge doesn't introduce an api and the spi just provides a simple
>> contract for starting the container as well as a bean-filter.
>> -> if needed, we could improve the implementation at any time.
>> imo we should add it before the release of v0.6 (since a lot of users
>> requested such a bridge).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2014/1/22 Jason Porter <[hidden email]>
>>
>> > I'd like to engage the Pivotal Team (anyone have contacts?) to see if we
>> > can get some of there help as well to create a really good integration.
>> >
>> >
>> > On Wed, Jan 22, 2014 at 2:12 AM, Gerhard Petracek <
>> > [hidden email]> wrote:
>> >
>> >> hi @ all,
>> >>
>> >> i would like to continue with this discussion.
>> >>
>> >> [1] describes a two-way bridge which is already based on deltaspike.
>> >> it offers a simple spi which allows more advanced add-ons like it is
>> >> mentioned in [2].
>> >>
>> >> regards,
>> >> gerhard
>> >>
>> >> [1]
>> >>
>> http://os890.blogspot.com/2013/12/add-on-spring-bridge-with-deltaspike.html
>> >> [2] http://os890.blogspot.com/2013/12/cdi-and-spring-mvc.html
>> >>
>> >>
>> >>
>> >> 2013/2/19 Matt Benson <[hidden email]>
>> >>
>> >>> Okay, I spent some time with Sam on IRC hashing this out.  Assuming
>> that
>> >>> Seam-Spring is covered under the SG(s?) Red Hat has filed for
>> deltaspike,
>> >>> his view is that it's not terribly important who does the initial code
>> >>> import, though it would be best for a so-authorized Red Hatter to be
>> the
>> >>> one to change the file headers.  I will be out of pocket for the rest
>> of
>> >>> the week beyond today, so if you, Marius, are able to work on the
>> import
>> >>> end of this week/early next then that's in any event as soon as I would
>> >>> have been able to get to it anyway.  Otherwise, anyone can do that,
>> with
>> >>> someone still employed by RH finally applying the change that modifies
>> >>> the
>> >>> headers--which, I suppose, could be prepared by anyone else and simply
>> >>> shared among our private git repos.
>> >>>
>> >>> Matt
>> >>>
>> >>>
>> >>> On Tue, Feb 19, 2013 at 12:07 AM, Marius Bogoevici <
>> >>> [hidden email]> wrote:
>> >>>
>> >>> > I still am a participant on this thread, but doing more reading than
>> >>> > writing as of late :)
>> >>> >
>> >>> > So, yes, I've been strapped for time with the job and the transition,
>> >>> but
>> >>> > I'd be happy to help out with this at the end of the week or early
>> >>> next.
>> >>> >
>> >>> > With my CLA on file, and the code being granted already, I'm not sure
>> >>> what
>> >>> > else needs to be done. I'm happy for the code to live in DeltaSpike,
>> >>> fwiw.
>> >>> >
>> >>> > On 2013-02-18, at 6:50 PM, Matt Benson <[hidden email]> wrote:
>> >>> >
>> >>> > > 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 <
>> >>> [hidden email]
>> >>> > >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 <
>> [hidden email]>
>> >>> > 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 <
>> [hidden email]
>> >>> >
>> >>> > >>> 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 <
>> >>> > >>>> [hidden email]> 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 <
>> >>> > >>> [hidden email]>:
>> >>> > >>>>>
>> >>> > >>>>>> 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 <
>> >>> > >>>>>> [hidden email]> wrote:
>> >>> > >>>>>>
>> >>> > >>>>>>> +1 it would definitively improve Java EE and CDI adoption.
>> >>> > >>>>>>>
>> >>> > >>>>>>> Antoine SABOT-DURAND
>> >>> > >>>>>>>
>> >>> > >>>>>>>
>> >>> > >>>>>>>
>> >>> > >>>>>>> Le 15 oct. 2012 à 09:41, Romain Manni-Bucau <
>> >>> [hidden email]
>> >>> > >
>> >>> > >>> 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 <[hidden email]>
>> >>> > >>>>>>>>
>> >>> > >>>>>>>>> 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 <[hidden email]>
>> >>> > >>>>>>>>>> To: [hidden email]
>> >>> > >>>>>>>>>> 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
>> >>> > >>
>> >>> >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> > Jason Porter
>> > http://en.gravatar.com/lightguardjp
>> >
>>
>
>
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp
12