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 17:39 ------- Encodings and OutputProperties ------------------------------ > Static values are maintained for each classloader. For each classloader, but not for each thread!!! I'm trying to setup following plugin structure (every plugin in own classloader): * solareclipse.ext.jaxp: JAXP API only. Implementation based on xml-commons and factories have additional changes to be able to find implementation through Eclipse extension-points. * solareclipse.ext.xerces (depends on JAXP): Xerces implementation of JAXP parser. * solareclipse.ext.xalan (depends on JAXP and Xerces): Xalan implementation of JAXP transformer. All works well if SUN JVM 1.3 is used. SUN JVM 1.4 (And IBM 1.3 as I remember) contains Xalan included into distribution. To be able to use non-system version of Xalan I am implementing classloading extension for 'endorsed' libraries which hides system supplied xalan and replaces it with own version (see http://bugs.eclipse.org/bugs/show_bug.cgi?id=29007 and core-dev mailing list). Note that Xalan could be replaced through JVM endorsed mechanism, but only once - you cannot use versioning and always locked to single version of Xalan in one JVM - i.e. if you have two plugins based on different versions of Xalan then you wouldn't be able to use them together if JVM has included Xalan! Same should apply to some possible application-server implementations... I'm quite succesfull in doing this extension, but Xalan refuses to work. Since context ClassLoader is system classloader by default, Encodings and OutputProperties are initialized from wrong resources. There is workaround - always set context ClassLoader before any use of Xalan and/or JAXP. But it is not convenient especially in case when you use exclusively JAXP API. And more, if you did not set it on first call, others will newer work even if you set appropriate context ClassLoader! Using of context ClassLoader in static initialization is bad practice in any case, because of dynamic nature of context ClassLoader; example: you cannot call non-static class methods from static methods! Initialization are done here in unpredictable way!!! System Properties ----------------- > Taking the SAX Driver property from XSLTInfo.properties should be faster > than using the Jar Service Provider Mechanism to find the class. This doesn't affect me. I can live with it, but... I think that it is responsibility of application initialization to set System properties, not a library responsibility! User of the library expects conformance in first place, i.e. lookup through services! If someone needs performance, he is able to set this property themselvs! Main problem I see here is usage of context ClassLoader here for STATIC initialization! These properties is bound to Xalan distribution, it is not an extension, and should be looked up through own Claslloader, but not some random thread context! And second (not about sax.driver) - there is only one instance of System properties, not per-classloader. If there is several classloaders with different versions of Xalan, properties that are set doesn't reflect reality... Then why to set them at all? Xalan itself doesn't use them!
