axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Schumann <>
Subject Re: Bug 17347 - Provider Lookup Fails within EARs
Date Mon, 03 Mar 2003 19:26:29 GMT
On 3/3/03 06:14 PM Steve Loughran <> wrote:

> ooh, first we have to enum the problems with different platforms.
> Tomcat: endorsed versus non-endorsed dirs on java1.4
> SunOne: recent postings about its contextClassloader being invalid
> WebLogic: doesnt explode WARs into directories, so whenever we ask for the
> physical path to something in the webapp, we get failure.

I think we should to take a look at classloader hierarchies found on these
platforms first. (I might be a little bit off the actual implementation -
since I am writing this out of my head).

Assuming EAR deployment Bea 6.x will create one EAR classloader (a child of
the system classloader) to load all ejb-jars in the EAR. For every .war
archive in this EAR a child of the EAR classloader will be created. If you
deploy war and ejb archives separately, one classloader (also a child of the
system classloader) will be created for every J2EE component.

Websphere 4.x is a little bit more complex, since it introduces the concept
of visibility for classloaders. I can't remember all details, but I know
there is one mode similar to the EAR deployment from weblogic, and another
one with "module" visibility. In this case all modules (war, ejb-jar and
Manifest Classpath entries) are loaded by a different classloader. Manifest
entries will make this more complex: The classloader of the jar containing a
Manifest reference will act as a child of the classloader which is
responsible for the referenced jar. In all cases these classloaders are
child's of the system classloader. (Btw. there are two other modes left).

JBoss on the other hand separates the system classloader and its own boot
classloader(s) strictly from the server instance classloaders - only a few
system classes are accessible to it. The core server deployment and
classloading infrastructure of Jboss is made of three parts: A
UnifiedClassloader, a shared class repository and deployers. JBoss removes
the standard parent delegation model in favour of the shared repository. To
make things short - apart from the EAR deployer all other deployers will
make their resources accessible through this shared repository. The EAR
deployer creates its own class repository (for its resources) and delegates
load requests only in case it does not find the given resource.

JRun behaves pretty similar to JBoss, since it uses the same JMX kernel.

So why did I spend that much time explaining class loading mechanisms? ;)
Because I would show that there is nothing you can be sure of while calling
getClass().getClassLoader() or currentThread().getContextClassLoader().

If somehow someone put axis.jar in the system classpath and uses weblogic or
websphere, it will be tough to access a resource inside the war. Same
applies to referenced modules inside Websphere. Ear deployment on bea 6.x
will force you in certain situations to reference or add all war archive
classes to all ejb archives, otherwise you will run into
ClassNotFoundExceptions. But - this also means that your this classes will
be loaded by the EAR classloader, not through the war archive classloader. I
don't know why, but using the exploded axis web archive on JBoss forced me
to copy the servlet classes in its WEB-INF/lib, otherwise usage of the admin
servlet would fail. But servlet classes are part of lib/ and should be
accessible through the shared repository.

So what do I recommend? Avoid using getClassloader().getResource() in web
archives at all ;). And btw - hot redeployment and JNDI object registration
makes things much worse ;).

(I haven't examined Orionserver/Oracle IAS and Pramati Server classloader
details, but I haven't had classloader issues apart from struts, earlier


> Attachments can be configured to go somewhere else, I believe
Yes, but default will be inside the war.


View raw message