Hi All, Here is quick glance on how java class artifacts within the contribution are resolved in 1.x and 2.x code base currently.
In 1.x code: - A ContributionClassLoaderProvider is registered using ContributionClassLoaderProviderExtensionPoint, which provides the ContributionClassLoader for the contributions. - A ContributionClassLoader instance is created for the contribution by the provider, and this instance of the classloader is set as a classloader to be used by the contribution within the ContributionImpl instance. - For the Java Class artifacts, the ClassLoaderModelResolver uses the class loader instance available from the contribution as the parent class loader while resolving the Class References. In 2.x code: - No ContributionClassLoaderProvider and ContributionClassLoaderProviderExtensionPoint is used. - The classloader field in the ContributionImpl is always null.** - For the Java Class artifacts, the ClassLoaderModelResolver uses the Thread.currentThread().getContextClassLoader() as the parent class loader to resolve the Class References. Not sure, about the reason why we are not using the ContributionClassLoaderProvider in 2.x code? 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. 2. Set the TCCL to the class loader of the contribution, from the JavaImplementationInvoker. Please let me know any suggestions and comments on this approach. Thanks. -- Thanks & Regards, Ramkumar Ramalingam
