On Wed, Apr 15, 2009 at 6:01 AM, Vamsavardhana Reddy <[email protected]> wrote: > 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 >
Hi Vamsi I'd like to run through and example where this problem is evident. I'm would expect to see that the resolve fails if it is, for example, unable to locate a java interface that is say contained within an EJB jar. Can you point me at a specific example or do I have to make one? Simon
