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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
