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.