You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by bu...@apache.org on 2002/05/19 08:04:12 UTC

DO NOT REPLY [Bug 8423] - AxisClassLoader cannot load service class

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8423>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8423

AxisClassLoader cannot load service class

gdaniels@macromedia.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED



------- Additional Comments From gdaniels@macromedia.com  2002-05-19 06:04 -------
FYI, the AxisClassLoader is actually deprecated at this point - there is no 
active code in Axis which uses it.  However the problem you mention will 
likely still occur since we do use the context classloader by default.

Classloader issues in container-managed environments are tricky.  Most servlet 
containers do apparently set the thread context classloader correctly, hence 
our default, but you can set it manually with MessageContext.setClassLoader() 
(this gets used by the JWS system, since each JWS class has a custom 
classloader much like JSPs do).

How does iPlanet manage to load its WEB-INF classes?  Does the system 
classloader somehow do this?  Would Class.forName("my.custom.class") work?

I'm marking this "assigned" for now, and we can hopefully work out how to deal 
with this once and for all.