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-01-28 15:49 -------
Encodings and OutputProperties:
-------------------------------

I could ask opposite question - why they should?
These classes and their properties are integral part. They all are always in the
same classloader! Java doesn't look for referenced classes in context
classloader, then why xalan should look for properties in some other
classloader. When it is used together with static fields it becomes madness.
Context ClassLoader is PER-THREAD (!!!), static fields belong to all threads
(!!!) and initialized only onece (from random CL!!!). In environment with
several classloaders (Eclipse platform, application-servers, etc.) if someone
does not properly initialized classloader on first call, then others will not be
able to use Xalan, even if you only use JAXP APIs. It is a violation of JAXP
specification as I understand it! In such multi-classloader environments Xalan
usualy belongs to some custom classloader, but context ClassLoader is system
ClassLoader. Then Xalan doesn't find resources, or finds incorrect ones (from
older version of Xalan in my case).

System Properties:
------------------

Why Xalan should replace SAX driver property to
org.xml.sax.driver=org.apache.xerces.parsers.SAXParser? What if I would like
other SAX Parser and have set it through "java -Dorg.xml.sax.driver=..."? I
wouldn't get it ant it is not what programmers expect. And why it does look a
properties file through thread context ClassLoader to initialize static data
(same issue as with Encodings and OutputProperties)?

Reply via email to