axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Schumann <>
Subject Re: what version of commons-discovery is being used in the latest version?
Date Tue, 25 Mar 2003 19:38:35 GMT
On 3/25/03 07:58 PM Eric.D.Friedman@WellsFargo.COM
<Eric.D.Friedman@WellsFargo.COM> wrote:

> Jens,
> What do the J2EE specs say about the classpath that app servers provide to
> deployed applications that use EARS?  Are the EAR files guaranteed to be in
> the classpath, or is it just the jars contained within the EAR?

See discussion on this list with Steve. The main issue is using
Thread.currentThread().getClassloader(). In my experience it is not safe to
say this classloader has access to all ear resources. You may have access to
WEB-INF/lib or WEB-INF/classes/ or you may not see those resources in the
way you expect them. In my case this approach just fails. Since it is quite
usual to refer to shared libraries between ejb-jars and war's or even
between ear files through Manifest.MF entries you end up in a classloader
nightmare. It seems that the use of the ServletContext Classloader is pretty
safe, but this introduces a Web Archive dependency.

I am pretty sure it works using (exploded) war archives, but as I said some
time ago, I haven't seen a plain war and even exploded deployment since a
long some time. If you deploy your application to a cluster it is just not
practical to do use something else than EARs.

J2EE specs does not say anything about classloaders. It only defines the
archive layout and requires that Manifest.MF classpath entries are


PS: I am still on the orion server problem someone described on axis-user,
now I really believe the J2EE application separation gets broken due to the
use of Thread.getCurrentThread().getClassoader(). Hopefully it is only a
classloader related JNDI problem ...

View raw message