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: [email protected]
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
