[ 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
