> Huh? I'm not sure what you mean. The JAXP specification is effectively
> a bunch of interfaces that anyone can implement (along with the rest of
> the docs, etc.). Apache happens to have several implementations of
Well, this I already know.
Yet, javax.xml.parsers.DocumentBuilderFactory and
javax.xml.transform.TransformerFactory are both *classes*, not *interfaces*.
Lets discuss DocumentBuilderFactory: the "newInstance" method is responsible
to get the factory, by searching four places:
1) javax.xml.parsers.DocumentBuilderFactory system setting
2) JAVA_HOME/lib/jaxp.properties
3) META-INF/services/javax.xml.parsers.DocumentBuilderFactory
4) The so-called "platform default DocumentBuilderFactory instance".
Now: In the JAXP reference implementation, Sun ships three JAR files:
1) jaxp.jar - javax.xml.parsers.*
2) crimson.jar
3) xalan.jar
jaxp.jar contains an implementation of
javax.xml.parsers.DocumentBuilderFactory. This implementation's
"newInstance" method does the search using the four steps above. When it
comes to step number 4, it looks for Crimson.
So, if tomorrow there'll be another vendor who wants to create a new XML
parser that follows JAXP, he'll have to write *his own* version of
javax.xml.parsers.DocumentBuilderFactory; in his own version, he'll make
newInstance() to look for "my.own.document.builder.Factory" instead of
"com.sun.blahblah".
Anyway, he won't be able to use Sun's distributed jaxp.jar. He'll write his
own implementation, with new bugs, new compatibility issues, etc.
This, in my opinion, should be avoided; and it can be avoided unless Sun
removes the 4th search-step.
- Isaac
---------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
