Hi Raymond comments in-line
Simon On Tue, Aug 17, 2010 at 11: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: 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 > [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 > ________________________________________________________________ > -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
