You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "A B (JIRA)" <de...@db.apache.org> on 2006/09/13 20:54:23 UTC
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Derby Info: [Release Note Needed]
Adding a release note to call out Derby's dependency on a JAXP parser and Apache Xalan when executing XML operators. First attempt at the release note is as follows:
DERBY-688: XML datatype and corresponding SQL/XML operators.
As of the 10.2 release, Derby supports a new XML data type and a set of operators that work with the XML data type. The XML data type and operators are based on a small subset of the SQL/XML specification.
PROBLEM
For the XML operators to work properly, Derby requires that a JAXP parser, such as Apache Xerces, and Apache Xalan are included in the Java classpath. If either the parser or Xalan are missing from the classpath, Derby disallows any XML-related operations.
SYMPTOM
If a user attempts to use any of the of XML operators but does not have a JAXP parser AND Apache Xalan in his/her classpath, the result will be an error similar to the following:
Failed to locate '<JAXP/Xalan>' API or implementation classes. XML operations are not permitted unless these classes are in your classpath.
CAUSE
Derby does all XML parsing by making calls to JAXP methods as defined in the JDK 1.4 API. Similarly, Derby does all evaluation of XPath queries, manipulation of XPath results, and serialization of XML values by making calls to Xalan-specific methods defined in Xalan classes. Thus if either JAXP or Xalan is missing from the classpath, the Derby XML operators would not function correctly, leading to ClassNotFound and similar exceptions at various points during code execution. In order to avoid this, Derby checks to see if JAXP and Xalan are in the classpath, and if either is missing, Derby will not even attempt to perform XML operations. Instead, it will just issue the error mentioned above.
SOLUTION
If you intend to use any of the Derby XML operators, make sure that you have 1) a JAXP parser and 2) Apache Xalan in your classpath. If you are running in client/server mode, the JAXP and Xalan classes must be in the classpath for the Derby server, since that is where XML-related processing actually occurs.
Apache Derby version 10.2 has been tested with Xalan 2.7.0. If you have a version of Xalan that is earlier than 2.7, the Derby XML operators may still work. However, it is possible that you will experience unexpected errors when using the Derby XML operators. For example, there is a bug in Xalan versions earlier than 2.5 that can lead to failures with Derby XML operators when Derby is running with a security manager. The exact error can vary depending on the situation, but generally includes a line similar to the following:
org.apache.xml.utils.WrappedRuntimeException: The resource [ file:////org/apache/xalan/serialize/XMLEntities.res ] could not load: java.security.AccessControlException: access denied
This problem has been fixed as of Xalan 2.5, so you can avoid the problem by using a more recent version of Xalan.
Note: Most Java virtual machines (JVMs) that are version 1.4 or later have a JAXP parser embedded in the JVM. If you are using one of these JVMs, you do not need to add any other JAXP classes to your classpath. Additionally, if the JVM that you are using includes an embedded version of Xalan, you should confirm that the version of Xalan satisfies the minimum requirements for Derby. For example, if your JVM is Sun JDK 1.4.2, you must override the version of Xalan in the JVM with a newer version. Use Java's Endorsed Standards Override Mechanisms described at http://java.sun.com/j2se/1.4.2/docs/guide/standards/ to override the version of Xalan.
If the JVM that you are using does not have a JAXP parser or a version of Xalan, you can add external versions of those classes in your classpath and Derby will pick up those classes.
WORKAROUND
There is no way to use the Derby XML operators without first including a JAXP parser and Apache Xalan in your classpath. Attempts to do so will result in an error.
> Enhancements to XML functionality to move toward XPath/XQuery support...
> ------------------------------------------------------------------------
>
> Key: DERBY-688
> URL: http://issues.apache.org/jira/browse/DERBY-688
> Project: Derby
> Issue Type: Improvement
> Components: SQL, JDBC
> Reporter: A B
> Assigned To: A B
> Priority: Minor
> Fix For: 10.2.2.0, 10.3.0.0
>
> Attachments: d688_phase1_v1.patch, d688_phase1_v1.stat, d688_phase1_v2.patch, d688_phase1_v3.patch, d688_phase2_v1_code.patch, d688_phase2_v1_tests.patch, d688_phase2_v2_tests.patch, d688_phase2_v3_tests.patch, d688_phase3_v1_code.patch, d688_phase3_v1_tests.patch, d688_phase4_v1.patch, d688_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_v1.patch, d688_phase7_v1.patch, derbyXMLSpec.html
>
>
> As of DERBY-334, Derby has some very basic support for XML that consists of an XML datatype and three operators (XMLPARSE, XMLSERIALIZE, and XMLEXISTS). I would like to enhance this existing functionality and, by doing so, help to move Derby incrementally toward a more usable and more complete XPath/XQuery solution (with emphasis on "incrementally").
> I have attached to this issue a document describing the particular changes that I am looking to make. At a high level, they consist of:
> 1) Making it easier to use the XML operators and datatype from within JDBC (ex. by implicit parsing/serialization of XML values).
> 2) Adding a new operator, XMLQUERY, to allow a user to retrieve the results of an XPath expression (instead of just determining whether or not the expression evaluates to an empty sequence, which is what XMLEXISTS does).
> 3) Making changes to the existing operators to line them up with the SQL/XML 2005 specification, and also to take steps toward my eventual hope of having support for XQuery (as opposed to just XPath) in Derby.
> If anyone has time and interest enough to look at the document and provide feedback, that'd be great...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira