On Wed, Apr 15, 2009 at 1:34 PM, Simon Laws <[email protected]> wrote: > 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 >
Re. the back slash problem I see you raised http://issues.apache.org/jira/browse/OPENEJB-1005 so is it safe to assume you're running with local fixes? Any other fixes that I would need to get to the same running state that you see? Simon
