Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Thu, 31 May 2007 23:05:39 +0200
From: Knut Anders Hatlen <Knut.Hatlen@Sun.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
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <x7ejkwr9ek.fsf@Sun.COM>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <20070531170005.56A0B1A981A@eris.apache.org>
 <465F015C.9070404@gmail.com> <x7wsyorhyd.fsf@Sun.COM>
 <465F1510.8090303@gmail.com>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1.50 (usg-unix-v)

Army <qozinx@gmail.com> writes:

> 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?

No, they fail with:

java.sql.SQLException: Java exception: 'org/apache/xml/utils/PrefixResolver: java.lang.NoClassDefFoundError'.

But both jdk15 and jdk16 have the PrefixResolver class in rt.jar. It's
just hidden in the com.sun.org.apache.xml.internal.utils
package. According to
http://java.sun.com/j2se/1.5.0/docs/guide/xml/jaxp/JAXP-Compatibility_150.html
it was placed there in order to make it easier to use a newer version
than the one bundled. The release notes for Java SE 1.5.0 say that it
contains "Xerces version 2.6.2 +".

> 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.

OK, so if we did some kind of reflection trick in SqlXmlUtil to use the
com.sun.org.apache.xalan package if org.apache.xalan wasn't there, that
would probably work.

> 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.

Hmm, there is also a com.sun.org.apache.xerces.internal.impl.xpath.XPath
class that we could check for. Its existence would at least give us the
same guarantee as org.apache.xpath.XPath, I think.

> 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...

If we require Xalan specific classes/methods and cannot only rely on
generic interfaces, then I agree, Xalan is what we should check for.

> Note that junit/XML.java relies on the same class
> ("org.apache.xpath.XPath") to assume Xalan exists, as well.  Hmm.

At least, it also checks that Xalan is there and meets the minimum
version requirements.

I'll log a JIRA issue for this, since it seems like a great usability
improvement not to require separate downloads when the JVM has what's
needed.

Thanks, Army!

-- 
Knut Anders