[
https://issues.apache.org/jira/browse/DERBY-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-6624:
--------------------------------------
Attachment: d6624-1a.diff
Attaching [^d6624-1a.diff] which removes the use of the org.w3c.dom.xpath
package and replaces it with the standard javax.xml.xpath package.
The main reason why it wasn't done as part of DERBY-2739, was that the
javax.xml.xpath interfaces require you to specify the return type of the XPath
queries when you evaluate them, and we don't know what the query will return
until after the query has been evaluated.
The patch works around this limitation by initially assuming that the XPath
query will return a set of nodes, and evaluate the query as if it actually
returns a set of nodes. If this fails, it reevaluates the query as one that
returns a scalar value. It caches the type information so that it won't have to
guess the type, and possibly reevaluate the query, the next time it is
executed. The type information is cached on the activation level, so it means
that the extra work to figure out the type typically only happens once when
accessing the first row the first time a statement is executed.
All the regression tests ran cleanly with the patch. I've successfully run the
XML tests on Oracle JDK 6, 7, 8 and 9. I've also run them successfully on Java
8 compact profile 2, but there I had to disable the security manager because of
DERBY-6625.
Details of the patch:
*java/engine/org/apache/derby/iapi/types/SqlXmlUtil.java*
Replace use of org.w3c.dom.xpath with javax.xml.xpath.
*java/engine/org/apache/derby/iapi/types/XML.java*
Change the checks for availability of XPath support. Instead of getting the
DOMImplementation instance and calling getFeature() on it, we now simply check
that the javax.xml.xpath.XPathFactory class is available on the classpath.
*java/engine/org/apache/derby/iapi/types/build.xml*
Build SqlXmlUtil using the ordinary build target, since no extra jar files need
to be on the classpath anymore.
*java/testing/org/apache/derbyTesting/junit/XML.java*
Stop looking for DOM level 3 XPath support to find out if the XML tests should
run. It now suffices to have a working XPathFactory.
*tools/java/xml-apis.jar*
Remove this jar file since it is no longer needed for building Derby.
*tools/ant/properties/extrapath.properties*
*tools/ide/netbeans/nbproject/project.xml*
Remove references to the deleted xml-apis.jar from the javadoc classpath and
the NetBeans classpath.
*tools/release/notices/xalan.txt*
*build.xml*
Remove the mentioning of Xalan in the NOTICE file, since there are no Xalan jar
files in source tree anymore.
> Use javax.xml.xpath interfaces for XPath support
> ------------------------------------------------
>
> Key: DERBY-6624
> URL: https://issues.apache.org/jira/browse/DERBY-6624
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.11.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: d6624-1a.diff
>
>
> Currently, Derby uses the interfaces in the org.w3c.dom.xpath package to
> implement XPath support. That package is not part of the Java SE
> specification. Even though the package is included as an internal API in some
> of the major Java runtimes, using the standard javax.xml.xpath package
> instead would be better. It would be more portable, and less likely to break
> in the future if JVM vendors remove the internal API.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
