On Wed, Apr 15, 2009 at 7:19 PM, Simon Laws <[email protected]>wrote:
> 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? Yes. > > > Any other fixes that I would need to get to the same running state that you > see? No. > > > Simon > -- Vamsi
