On Tue, Aug 17, 2010 at 3:49 PM, Raymond Feng <[email protected]> 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/
