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=16481>. 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=16481 Incorrect usage of context ClassLoader for static field initialization ------- Additional Comments From [EMAIL PROTECTED] 2003-02-06 13:56 ------- The issue of this bug is not a change in ClassLoading strategy in general (a change in strategy is requested in bug #16675 with explanations why it doesn't change semantics of 'normal' classloaders). I try to summrize again the issue of this bug and why I'm absolutely shure it is incorrect. Read it carefully and you'll understand that I'm rigt: 1. Any static field is one per ClassLoader. It initialized only once at first call. There might be any numbers of threads! Then which thread's context ClassLoader should be used for initialization? Answer could be only one - doesn't use context ClassLoader at all!!! The most natural way is to use current ClassLoader! And since resource is always bundled together with class (i.e. same ClassLoader) this way is absolutely right. 2. It doesn't prevent different web applications from having different copies of Encodings and OutputProperties. If someone wants customized copies for Encodings and OutputProperties then: a) It is unlikely (since these properties standards-defined: W3C defined defaults which could be overriden in XSLT stylesheet). b) If it really required then this should be done some other 'STATIC' way (for example by placing appropriate .properties resources somewhere where classloader would look before xalan.jar, /WEB-INF/classes is consulted before any /WEB-INF/lib/*.jar in web containers so could be used for such owerride). c) Do not cache these classes and reload on every call, which is ineffective especially for [a]. Draw attention that even in case with usage of context ClassLoader you MUST put overriden version somewhere where classloader would look before xalan.jar like described in [b]!!! I.e. your assumption that my change breaks this possibility is incorrect. In Eclipse you can't control Context ClassLoader in framework because there is no single source of control as in web-containers. Any plugin could do calls to any other... But angain it is a different issue - here we talk about static fields where any dependency on thead context is simply inappropriate!
