axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Schumann <j...@void.fm>
Subject Re: SV: AXIS classloaders breaking J2EE application isolation
Date Wed, 19 Mar 2003 23:44:56 GMT
On 3/19/03 11:54 PM David Ekholm <david.ekholm@netentertainment.com> wrote:

>> Hmm. 
> 
>> What do you mean by "share a common classpath"? They all refer to the same
>> jar within an EAR? Or you added the class to the system classpath?
> 
> In our system we don't pack each application to EARs, we leave them unpacked.
> Each application.xml refers to the same classpath, -a path to a directory

> In short: AXIS is probably not breaking a rule here with its implementation,
> but with an adjustment to how it uses classloaders, it would be more
> compatible with existing J2EE solutions. -Solutions that may not be 100%
> orthodox, but solutions that look the way they do for a good reason.


Ok. I see what your are talking about. The problem is, Magnus does not
respond anymore (probably got too rich after the oracle deal ;). So it would
be good to make sure orion does use different classloaders to load the
common jar resources you are referring to. From what you are describing it
sounds like the class gets loaded just once for all applications. As far I
can tell axis does not do anything wrong apart from using current thread
classloaders (which might lead to classnotfound issues, but see side effects
below). 
 
Are you sure you don't run into the same problem using the same approach
without axis? If there would have been clear separation from orion you would
not be able to alter attributes of another application.
 
I remember one issue using a different application server, which might help:
This application server is using different principals during deployment and
at runtime. It sounds correct, but they forgot to change the principal
before start auto start servlets - so you were running in all kinds of
security problems during startup.

So my question is: Do you access your common statics using a static
initializer or equal inside EJBs? Because then the axis current thread
context classloader approach might be a problem, in conjunction with a
broken deployment process in orion. I could image a global deployment thread
which does have access to all resources through its classloader.


Finally: To be honest, there is no easy fix, because it all depends on the
app server classloader hierarchy ... And this is a major nightmare. I hope I
can free some time shortly ...
   

Jens


Mime
View raw message