I think this problem with locating an interface will not arise in case of EJB jar. Easiest way to recreate this would be to have an interface element under a reference in implementation.web component in a WAR file. You can use one of the web apps from the samples under [1].
[1] https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/samples On Wed, Apr 15, 2009 at 5:34 PM, Simon Laws <[email protected]>wrote: > 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 > -- Vamsi
