db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
Date Wed, 13 Sep 2006 18:54:23 GMT
     [ 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.


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.


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. 


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.


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.


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:,
>         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


View raw message