db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@gmail.com>
Subject Re: svn commit: r543183 - in /db/derby/code/trunk/java: engine/org/apache/derby/impl/sql/compile/UnaryOperatorNode.java testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java
Date Thu, 31 May 2007 18:33:52 GMT
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 

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.


View raw message