axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric.D.Fried...@WellsFargo.COM
Subject RE: what version of commons-discovery is being used in the latest version?
Date Tue, 25 Mar 2003 19:55:22 GMT
I assume you mean Thread.currentThread().getContextClassLoader().  That's
*supposed* to work for this purpose, but it's not hard to believe that there
are problems between vendors.  What would happen if your application code
set the thread's contextclassloader to be your servlet context class loader?
This is what your application server vendor is supposed to have done, but if
it isn't so, can you ...correct the problem?

I should also mention that I noticed that commons-discovery contains support
for passing in an object whose class' loader will be used as the basis of
the search.  That might a useful way to make the behavior more
deterministic.

Eric


-----Original Message-----
From: Jens Schumann [mailto:jens@void.fm]
Sent: Tuesday, March 25, 2003 11:39 AM
To: axis-dev@ws.apache.org
Subject: Re: what version of commons-discovery is being used in the
latest version?


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
supported.

Jens 

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 ...

Mime
View raw message