Hi Ram A couple of comments
...snip > - For the Java Class artifacts, the ClassLoaderModelResolver uses the > Thread.currentThread().getContextClassLoader() as the parent class loader to > resolve the Class References. It may be that the parent classloader for the ClassLoaderModelResolver is the TCCL (which I imagine is the Tuscany runtime classloader) but this is not the main mode of operation for the ClassLoaderModelResolver. If you look at the code for that class you'll see that the ClassLoaderModelResolver does two main things. - Collects together all the Java imports for the contribution and uses these first to try and resolve the class - Populates its base class URLClassloader with the artifacts from the contribution to which it refers and uses this second to try and resolve the class It treats resource slightly differently but using the same basic techniques snip... > > According to the current specs "The SCA runtime MUST set the thread context > class loader of a component implementation class to the class loader of its > containing contribution. [JCI100009]". To comply with the current specs, I > believe the following changes are required in 2.x code base.... > > 1. Use the ContributionClassLoaderProviderExtensionPoint to register a > ContributionClassLoaderProvider, and allow the > ContributionClassLoaderProvider to create a ContributionClassLoader instance > for each contribution. I think we should be using ClassLoaderModelResolver but is you question here how you get hold of it in the JavaImplementationInvoker? > 2. Set the TCCL to the class loader of the contribution, from the > JavaImplementationInvoker. +1 Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
