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
[email protected]
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
________________________________________________________________

Reply via email to