On Wed, Apr 15, 2009 at 1:24 PM, Vamsavardhana Reddy <[email protected]> wrote: > 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 >
Thanks Vamsi When I said "unable to locate a java interface that is say contained within an EJB jar" what I meant was "unable to local an interface.java which references a java interface contained within an EJB.jar". And I'm particularly thinking of the case where the application composite is in a EAR that contains the EJB jar. I have been looking at the EAR example in itest/contribution-jee but they are failing for me as OpenEJB seems to be struggling with windows back slashes. Does this itest work for you? Also, from my other post, where is the source for the test applications here? Regards Simon
