The contribution classloader for an SCA contribution containing Java EE artifacts is not as straight forward as a URL classloader that checks nested jars in the contribution for class lookup apart from the classes in the archive. Since the scheme used by class loaders for Java EE archives is different from the existing ContributionClassLoader (for e.g., in case of a WAR archive, the classloader will be using the jars under WEB-INF/lib and classes under WEB-INF/classes), we have to come with new class loader mechanisms. Currently there is a ContributionClassLoaderProvider utility provided through UtilityExtensionPoint and Tuscany is using a DefaultContributionClassLoaderProvider.
Some of the ideas that I have are: 1. Have the current JavaEE introspection extension point return a class loader for the archive introspected. 2. Have an extension point or a utility to return/resolve(?) a class loader based on the URI of the artifact passed as parameter. Then create a new ContributionClassLoaderProvider to override the default one incase the runtime supports Java EE implementation types. Another aspect that we need to consider is that incase of EAR application, there are multiple classloaders at play, like the Application classloader with common libraries, EJB classloader with all EJB modules in the EAR and one classloader per web module. So, the contribution classloader will have to manage more than one classloader under the covers and delegate class loading to appropriate class loader. During the build phase, the Java EE introspection code may be creating temporary classloaders (like OpenEJB does at the moment) to obtain the metadata required for deployment. And at runtime the classloaders are different and in most cases the classes are available in the thread context classloader. It becomes more complicated in the case of nested EARs (i.e., an EAR contribution packaging another EAR inside). One way I can think of handling this is by viewing the contribution as a heirarchy of logical contributions and having implicit imports. I would like others comments and suggestions so that we can iron out these rough edges in contribution classloaders for Java EE contributions. Thanks, Vamsi
