Knut Anders Hatlen wrote:
You're right that it fails with Sun jdk15 and jdk16 when Xalan is not in classpath. However, this simple change in XML.checkXMLRequirements() made CollationTest run just fine:Index: java/engine/org/apache/derby/iapi/types/XML.java =================================================================== --- java/engine/org/apache/derby/iapi/types/XML.java (revision 543186) +++ java/engine/org/apache/derby/iapi/types/XML.java (working copy) @@ -910,7 +910,9 @@ * point in checking for Xalan unless we've already confirmed * that we have the JAXP interfaces. */ - else if (!ClassInspector.classIsLoadable("org.apache.xpath.XPath")) + else if (!ClassInspector.classIsLoadable("org.apache.xpath.XPath") + && + !ClassInspector.classIsLoadable("javax.xml.xpath.XPath")) xmlReqCheck = "Xalan"; } Does this mean that the XML functionality works in Sun's JVMs too without external Xalan jars, if we only check different package names, or is there something else missing?
Hmm, great question. Do lang/XMLTypesAndOpsTest and lang/XMLBindingTest pass, as well?
When the XML type was added to Derby it was with jdk 1.4 in mind, and javax.xml.xpath.XPath doesn't exist for 1.4. So that's probably why it wasn't included.
If the above change works for 1.5 and 1.6, I assume this means those JVMs embedd Xalan internally, is that correct? The reason I assume this is because the iapi/types/SqlXmlUtil class imports xalan classes ("org.apache.xalan..."), so I think things should have failed unless Xalan is embedded within the jvm.
In any event, the existing code makes an assumption here (which is also mentioned in the code comments): if "org.apache.xpath.XPath" exists, then we assume it exists as part of Xalan. Is it safe to make that same assumption with "javax.xml.xpath.XPath"? My guess is that the latter is a much more risky assumption, as any 1.5/1.6 JVM could have "javax.xml.xpath.XPath" without actually relying on Xalan. The "org.apache.xpath.XPath" check is only marginally better: at least we know it comes from Apache, which we could argue "suggests" Xalan. But in truth, even that seems a tad risky.
I think a bigger question is: should we be explicitly checking for a *Xalan* class instead of checking for some indirect class (currently "org.apache.xpath.XPath")? Ultimately Xalan is what Derby wants, so shouldn't be we looking for that directly? That seems like a more correct approach; I'm not sure why the code doesn't explicitly look for Xalan today. If there was a reason, I don't recall it...
Note that junit/XML.java relies on the same class ("org.apache.xpath.XPath") to assume Xalan exists, as well. Hmm.
Army
