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 [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 ________________________________________________________________ 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 <[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
