[DISCUSS] implementation.spring module structure

[Raymond Feng <en...@gmail.com>]

Hi,

Recently, I have been fixing issues around the implementation.spring extension in order to bring up a real world Spring application. There are two painful areas:

1) We use our own StAX parsing code to load the Spring XML bean definitions. I appreciate the coding efforts to support fair amount of Spring xml syntax but it seems to be a blackhole ahead of us. In the Spring xml definition I have, there are many edge cases that Tuscany code cannot handle. I'm not sure why we didn't choose to use the Spring XML bean definition loader to handle that. 

2) I understand from the README that our implementation.spring is structured specially to support the case where Spring classes and Tuscany classes are not visible to each other (loaded by different class loaders). In my case, I always have Spring and Tuscany being loaded by the same class loader (either in the same web application or in the same lib). I'm not sure for users like me, why we have to pay the penalty to use "stub/tie" to jump between the classloaders using expensive reflective calls?

I propose that we refactor the related modules to support both scenarios (A: same classloader or B: separate classloader for Tuscany and Spring) as follows:

1) implementation-spring (only contains the model and xml parsing code)
2) implementation-spring-runtime (contains the runtime providers, extensions to Spring schema and handlers)

3) implementation-spring-stub (contains the runtime providers and stub code that calls into Spring reflectively)
4) implementation-spring-tie (contains the tie code that invokes Spring and calls back Tuscany reflectively)

For A: we just use module 1 and 2. 
For B: we need to have module 1 and 3 in Tuscany lib and 4 in the application.

Module 2 and 3 can plug in implementation of certain SPIs into module 1.

I'll check in a copy of module 1 and 2 into the contrib for now.

Thanks,
Raymond
________________________________________________________________ 
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________

Re: [DISCUSS] implementation.spring module structure

[Raymond Feng <en...@gmail.com>]

I have now added all of the modules under contrib/modules. I also did a smoke test with itest-implementation-spring for the following combinations:

1) implmentation-spring and implementation-spring-runtime 
2) implmentation-spring, implementation-spring-stub and implementation-spring-tie 
3) implmentation-spring, implementation-spring-runtime, and implementation-spring-stub  (Testing potential conflicts)
4) implmentation-spring, implementation-spring-runtime, implementation-spring-stub and implementation-spring-tie (Testing potential conflicts)

For 2, 3, 4, I fixed DefaultProviderFactoryExtensionPoint to honor the rankings. 

For 4) the Tuscany extensions such as the xml processor and providers work in favor of the ones from implementation-spring-runtime (with higher rankings). The only caveat is the spring namespace handler is keyed by the namespace. I expect people won't have implementation-spring-tie there :-).

Please give a try. If everything goes well, I'll start to push them into trunk.

Thanks,
Raymond
________________________________________________________________ 
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________

On Aug 18, 2010, at 5:27 AM, Simon Laws wrote:

> Hi Raymond
> 
> comments in-line
> 
> Simon
> 
> On Tue, Aug 17, 2010 at 11:49 PM, Raymond Feng <en...@gmail.com> wrote:
>> Hi,
>> Recently, I have been fixing issues around the implementation.spring
>> extension in order to bring up a real world Spring application. There are
>> two painful areas:
> 
> Sounds Ok to me. Anything that mean less Tuscany code to main for the
> same (or better) function sounds good.
> 
>> 1) We use our own StAX parsing code to load the Spring XML bean definitions.
>> I appreciate the coding efforts to support fair amount of Spring xml syntax
>> but it seems to be a blackhole ahead of us. In the Spring xml definition I
>> have, there are many edge cases that Tuscany code cannot handle. I'm not
>> sure why we didn't choose to use the Spring XML bean definition loader to
>> handle that.
>> 2) I understand from the README that our implementation.spring is structured
>> specially to support the case where Spring classes and Tuscany classes are
>> not visible to each other (loaded by different class loaders). In my case, I
>> always have Spring and Tuscany being loaded by the same class loader (either
>> in the same web application or in the same lib). I'm not sure for users like
>> me, why we have to pay the penalty to use "stub/tie" to jump between the
>> classloaders using expensive reflective calls?
>> I propose that we refactor the related modules to support both scenarios (A:
>> same classloader or B: separate classloader for Tuscany and Spring) as
>> follows:
>> 1) implementation-spring (only contains the model and xml parsing code)
>> 2) implementation-spring-runtime (contains the runtime providers, extensions
>> to Spring schema and handlers)
>> 3) implementation-spring-stub (contains the runtime providers and stub code
>> that calls into Spring reflectively)
>> 4) implementation-spring-tie (contains the tie code that invokes Spring and
>> calls back Tuscany reflectively)
>> 
>> For A: we just use module 1 and 2.
>> For B: we need to have module 1 and 3 in Tuscany lib and 4 in the
>> application.
>> Module 2 and 3 can plug in implementation of certain SPIs into module 1.
>> I'll check in a copy of module 1 and 2 into the contrib for now.
> 
> Sounds OK in principle. Off the top of my head I don't know if there
> are any gotchas in there. It you're checking in example
> implementations of 1-4 to contrib then, as someone interested in
> scenario B, I can give it a go and see what happens.
> 
>> Thanks,
>> Raymond
>> ________________________________________________________________
>> Raymond Feng
>> rfeng@apache.org
>> Apache Tuscany PMC member and committer: tuscany.apache.org
>> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
>> Personal Web Site: www.enjoyjava.com
>> ________________________________________________________________
>> 
> 
> -- 
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: [DISCUSS] implementation.spring module structure

[Simon Laws <si...@googlemail.com>]

Hi Raymond

comments in-line

Simon

On Tue, Aug 17, 2010 at 11:49 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
> Recently, I have been fixing issues around the implementation.spring
> extension in order to bring up a real world Spring application. There are
> two painful areas:

Sounds Ok to me. Anything that mean less Tuscany code to main for the
same (or better) function sounds good.

> 1) We use our own StAX parsing code to load the Spring XML bean definitions.
> I appreciate the coding efforts to support fair amount of Spring xml syntax
> but it seems to be a blackhole ahead of us. In the Spring xml definition I
> have, there are many edge cases that Tuscany code cannot handle. I'm not
> sure why we didn't choose to use the Spring XML bean definition loader to
> handle that.
> 2) I understand from the README that our implementation.spring is structured
> specially to support the case where Spring classes and Tuscany classes are
> not visible to each other (loaded by different class loaders). In my case, I
> always have Spring and Tuscany being loaded by the same class loader (either
> in the same web application or in the same lib). I'm not sure for users like
> me, why we have to pay the penalty to use "stub/tie" to jump between the
> classloaders using expensive reflective calls?
> I propose that we refactor the related modules to support both scenarios (A:
> same classloader or B: separate classloader for Tuscany and Spring) as
> follows:
> 1) implementation-spring (only contains the model and xml parsing code)
> 2) implementation-spring-runtime (contains the runtime providers, extensions
> to Spring schema and handlers)
> 3) implementation-spring-stub (contains the runtime providers and stub code
> that calls into Spring reflectively)
> 4) implementation-spring-tie (contains the tie code that invokes Spring and
> calls back Tuscany reflectively)
>
> For A: we just use module 1 and 2.
> For B: we need to have module 1 and 3 in Tuscany lib and 4 in the
> application.
> Module 2 and 3 can plug in implementation of certain SPIs into module 1.
> I'll check in a copy of module 1 and 2 into the contrib for now.

Sounds OK in principle. Off the top of my head I don't know if there
are any gotchas in there. It you're checking in example
implementations of 1-4 to contrib then, as someone interested in
scenario B, I can give it a go and see what happens.

> Thanks,
> Raymond
> ________________________________________________________________
> Raymond Feng
> rfeng@apache.org
> Apache Tuscany PMC member and committer: tuscany.apache.org
> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
> Personal Web Site: www.enjoyjava.com
> ________________________________________________________________
>

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: [DISCUSS] implementation.spring module structure

[Luciano Resende <lu...@gmail.com>]

On Tue, Aug 17, 2010 at 3:49 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
> Recently, I have been fixing issues around the implementation.spring
> extension in order to bring up a real world Spring application. There are
> two painful areas:
> 1) We use our own StAX parsing code to load the Spring XML bean definitions.
> I appreciate the coding efforts to support fair amount of Spring xml syntax
> but it seems to be a blackhole ahead of us. In the Spring xml definition I
> have, there are many edge cases that Tuscany code cannot handle. I'm not
> sure why we didn't choose to use the Spring XML bean definition loader to
> handle that.

Agree, I also think that there might be cases where new
elements/attributes get introduced in new Spring releases and we will
need to keep maintaining this which might get us some headaches.

> 2) I understand from the README that our implementation.spring is structured
> specially to support the case where Spring classes and Tuscany classes are
> not visible to each other (loaded by different class loaders). In my case, I
> always have Spring and Tuscany being loaded by the same class loader (either
> in the same web application or in the same lib). I'm not sure for users like
> me, why we have to pay the penalty to use "stub/tie" to jump between the
> classloaders using expensive reflective calls?

I think this is also the most common scenarios with most of people
using Tuscany SCA/Spring integration.

> I propose that we refactor the related modules to support both scenarios (A:
> same classloader or B: separate classloader for Tuscany and Spring) as
> follows:
> 1) implementation-spring (only contains the model and xml parsing code)
> 2) implementation-spring-runtime (contains the runtime providers, extensions
> to Spring schema and handlers)
> 3) implementation-spring-stub (contains the runtime providers and stub code
> that calls into Spring reflectively)
> 4) implementation-spring-tie (contains the tie code that invokes Spring and
> calls back Tuscany reflectively)
>


Let me see if I understood this correctly :

> For A: we just use module 1 and 2.

This are the regular users that have both Tuscany and Spring in the
same classloader and the most common scenario. They would use
implementation-spring/implementation-spring-runtime following the same
pattern used by all other Tuscany extensions. In this scenario, we
will also add enhancements to delegate some processing of spring
specific artifacts back to Spring handlers.

Then +1

> For B: we need to have module 1 and 3 in Tuscany lib and 4 in the
> application.
> Module 2 and 3 can plug in implementation of certain SPIs into module 1.
> I'll check in a copy of module 1 and 2 into the contrib for now.

This is the embeddeders or other users which don't have Tuscany and
Spring in the same classloader scenario, and then they would need to
use the implementation-spring/implementaiton-spring-stub/implementation-spring-tie
which use reflective calls to jump between classloaders.

Agreed too, this should give the same level of support for this
specific scenario, while giving flexibility to new optimizations on
the most used scenarios.


-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: [DISCUSS] implementation.spring module structure

[Raymond Feng <en...@gmail.com>]

The code is checked under contrib/modules:

See https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/contrib/modules/implementation-spring-runtime/src/main/java/org/apache/tuscany/sca/implementation/spring/namespace/ScaServiceBeanDefinitionParser.java

The idea is to use Spring extension handler to capture the sca extension elements and store them at the special application context subclass from Tuscany.

Thanks,
Raymond
________________________________________________________________ 
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________

On Aug 19, 2010, at 7:58 AM, Mike Edwards wrote:

> Raymond Feng wrote:
> <snip>
>> 1) We use our own StAX parsing code to load the Spring XML bean definitions. I appreciate the coding efforts to support fair amount of Spring xml syntax but it seems to be a blackhole ahead of us. In the Spring xml definition I have, there are many edge cases that Tuscany code cannot handle. I'm not sure why we didn't choose to use the Spring XML bean definition loader to handle that. 
> <snip>
>> Thanks,
>> Raymond
> 
> Raymond,
> 
> How are you proposing to handle the parsing of the SCA extensions to the Spring XML?
> 
> 
> Yours,  Mike.
> 

Re: [DISCUSS] implementation.spring module structure

[Mike Edwards <mi...@gmail.com>]

Raymond Feng wrote:
<snip>
> 
> 1) We use our own StAX parsing code to load the Spring XML bean 
> definitions. I appreciate the coding efforts to support fair amount of 
> Spring xml syntax but it seems to be a blackhole ahead of us. In the 
> Spring xml definition I have, there are many edge cases that Tuscany 
> code cannot handle. I'm not sure why we didn't choose to use the Spring 
> XML bean definition loader to handle that. 
> 
<snip>
> Thanks,
> Raymond

Raymond,

How are you proposing to handle the parsing of the SCA extensions to the Spring XML?


Yours,  Mike.