DO NOT REPLY [Bug 26613] - AbstractDOMParser setDocumentClassName ClassLoader problem

[bu...@apache.org]

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

AbstractDOMParser setDocumentClassName ClassLoader problem





------- Additional Comments From igor@widespace.ee  2004-02-15 17:10 -------
Vary similar bug report (and probably the same problem) - see #24244

Bellow is my IMHOs and a bit messy thoughts...

I don't thing that proposed fix is a good solution for the problem. Xerces (and
Xalan) has many places where dynamic class-loading is used, and it is required
for extensibility. The fix is only for one such place. But it should be fixed
either generally, or should be declared as limitation. Fixing it in one place
makes classloading strategy different in different places and only makes Xerces
less stable concerning classloading.

Actually the problem seems to be in not 100% correct behavior of Websphere 5.0.2
classloader. As suggested by java specs any good-behaving classloader should
delegate classloading to it's parent _before_ trying to resolve class by its
own... From your description I could conclude that it does not do this.

Josh, isn't it more appropriate for you to use web-app loaded Xerces instance
instead of instance from system classloader? It is very hard to get both
instances working right in presence of "not playing by rules" classloaders (and
in place of "playing by rules" classloader you will get only one instance of
classes from parent classloader, and child classloader will not owerride classes
loaded by parent).

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org