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):
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
> 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
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!