Re: [DISCUSS] Contribution classloaders when SCA contribution contains Java EE artifacts

[Raymond Feng <en...@gmail.com>]

Let's take an example: an ear file (helloworld.ear) containing a web module 
and ejb module. The application.composite is follows:

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" 
targetNamespace="http://sample" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
name="Helloworld-web">
    <component name="helloworldWebComponent">
        <implementation.web web-uri="helloworld-web.war" />
        <reference name="helloworldSca" 
target="helloworldEjbComponent/HelloworldService">
            <interface.java interface="hello.HelloworldService"/> <!--A -->
        </reference>
    </component>
    <component name="helloworldEJBComponent">
        <implementation.ejb ejb-link="helloworld-ejb.jar#HelloworldEJB" />
        <service name="HelloworldEJB">
            <interface.java interface="hello.HelloworldService"/> <!--B -->
        </service>
    </component>
</composite>

I don't think the EAR itself can contain java classes. The java classes will 
be packaged inside WARs, EJB jars or utility jars.

1) How do we expect A to be loaded? From helloworld-web.war (WEB-INF/classes 
and WEB-INF/lib/*.jar, also following the ClassPath entry in MANIFEST.MF)?
2) How do we expect B to be loaded? From helloworld-ejb.jar (also following 
the ClassPath entry in MANIFEST.MF)?

It seems that there is a context (such as the WAR or EJB jar) to resolve the 
java types.

Thanks,
Raymond

From: Vamsavardhana Reddy
Sent: Tuesday, April 14, 2009 10:01 PM
To: dev@tuscany.apache.org
Subject: [DISCUSS] Contribution classloaders when SCA contribution contains 
Java EE artifacts


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 

Re: [DISCUSS] Contribution classloaders when SCA contribution contains Java EE artifacts

[Simon Laws <si...@googlemail.com>]

On Wed, Apr 15, 2009 at 5:50 PM, Raymond Feng <en...@gmail.com> wrote:
> Let's take an example: an ear file (helloworld.ear) containing a web module
> and ejb module. The application.composite is follows:
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> targetNamespace="http://sample" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> name="Helloworld-web">
>   <component name="helloworldWebComponent">
>       <implementation.web web-uri="helloworld-web.war" />
>       <reference name="helloworldSca"
> target="helloworldEjbComponent/HelloworldService">
>           <interface.java interface="hello.HelloworldService"/> <!--A -->
>       </reference>
>   </component>
>   <component name="helloworldEJBComponent">
>       <implementation.ejb ejb-link="helloworld-ejb.jar#HelloworldEJB" />
>       <service name="HelloworldEJB">
>           <interface.java interface="hello.HelloworldService"/> <!--B -->
>       </service>
>   </component>
> </composite>
>
> I don't think the EAR itself can contain java classes. The java classes will
> be packaged inside WARs, EJB jars or utility jars.
>
> 1) How do we expect A to be loaded? From helloworld-web.war (WEB-INF/classes
> and WEB-INF/lib/*.jar, also following the ClassPath entry in MANIFEST.MF)?
> 2) How do we expect B to be loaded? From helloworld-ejb.jar (also following
> the ClassPath entry in MANIFEST.MF)?
>
> It seems that there is a context (such as the WAR or EJB jar) to resolve the
> java types.
>
> Thanks,
> Raymond
>
snip...

I think you are right that there is context to help us, for example,
as Vamsi points out, OpenEJB that Tuscany is using to perform the JEE
archive introspection builds a classloader hierarchy to reflect the
JEE archive structure (as you might expect). However I'm going to push
you on what you mean by context here.

Do you mean TCCL type of context? We are faced with a number of
scenarios depending on how the JEE archive is packaged (See the
Archive Location Scenarios section of [1]). When may, for example,
have a JEE archive that itself is a contribution (E) or the JEE
archive may be embedded in a contribution (B). We have to provide a
mechanism whereby we can explicitly get at the context.

So, some points derived from what Vamsi said...

1. We know that all container classloaders are not created equal so we
need some API to allow an integrator to return the archive classloader
 back to the SCA resolution code

e.g. we could push it into the
WebModuleInfoImpl/EarModuleInfo/JavaEEApplicationInfo objects that
contribution-jee supports

2. We need to integrate this context with the contribution
classloader. At the moment it doesn't find the class in the current
contribution or in any imports

e.g. we could create a new contribution classloader that knows how to
deal with JEE class loader hierarchies

3. In dealing with the JEE classloaders we need to be smart about how
we find a class. The model resolver is just doing a class for name but
we have to start at various parts of the JEE classloader hierarchy as
we don't necessarily know whether the class we are looking for is in
an EJB/util jar or in on of the web apps.

e.g. we could just look until we find it or run out of classloaders
but I don't know how you find the web app classloaders unless you are
explicitly given them.

4. Assuming we are going to go on and build and start the model we
have to make sure that we get the runtime classloaders that the
container is using to actually load the JEE classes for real. Not sure
precisely what we can do about this other than provide suitable APIs
such that the container runtime can provide this info.

Simon



[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Java+EE+Integration