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 Army <qo...@gmail.com> on 2007/05/31 19:09:48 UTC
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
mamta@apache.org wrote:
> +
> + s.executeUpdate("set schema APP");
> + checkLangBasedQuery(s, "SELECT XMLSERIALIZE(x as CHAR(10)) " +
> + " FROM xmlTable, SYS.SYSTABLES WHERE " +
> + " XMLSERIALIZE(x as CHAR(10)) = TABLENAME",
> + null);
Just for the record, I think use of XMLSERIALIZE here will fail if the test
classpath does not include the required Xalan/JAXP classes (ex. Sun jdk15 with
no external XML jars). It might be good to wrap this particular test inside of an
if (XML.classpathMeetsXMLReqs())
....
where "XML" is junit/XML.java. I think that's all that would be needed, though
I haven't actually tried it out...
Army
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
Posted by Mamta Satoor <ms...@gmail.com>.
Army, I just changed the test with commit 543209. Please let me know if you
see any further issues.
Mamta
On 5/31/07, Mamta Satoor <ms...@gmail.com> wrote:
>
> Thanks, Army. I will work on making these changes.
>
> Mamta
>
>
> On 5/31/07, Army <qo...@gmail.com> wrote:
> >
> > mamta@apache.org wrote:
> > > +
> > > + s.executeUpdate("set schema APP");
> > > + checkLangBasedQuery(s, "SELECT XMLSERIALIZE(x as CHAR(10)) " +
> > > + " FROM xmlTable, SYS.SYSTABLES WHERE " +
> > > + " XMLSERIALIZE(x as CHAR(10)) = TABLENAME",
> > > + null);
> >
> > Just for the record, I think use of XMLSERIALIZE here will fail if the
> > test
> > classpath does not include the required Xalan/JAXP classes (ex. Sun
> > jdk15 with
> > no external XML jars). It might be good to wrap this particular test
> > inside of an
> >
> > if (XML.classpathMeetsXMLReqs())
> > ....
> >
> > where "XML" is junit/XML.java. I think that's all that would be needed,
> > though
> > I haven't actually tried it out...
> >
> > Army
> >
> >
>
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
Posted by Mamta Satoor <ms...@gmail.com>.
Thanks, Army. I will work on making these changes.
Mamta
On 5/31/07, Army <qo...@gmail.com> wrote:
>
> mamta@apache.org wrote:
> > +
> > + s.executeUpdate("set schema APP");
> > + checkLangBasedQuery(s, "SELECT XMLSERIALIZE(x as CHAR(10)) " +
> > + " FROM xmlTable, SYS.SYSTABLES WHERE " +
> > + " XMLSERIALIZE(x as CHAR(10)) = TABLENAME",
> > + null);
>
> Just for the record, I think use of XMLSERIALIZE here will fail if the
> test
> classpath does not include the required Xalan/JAXP classes (ex. Sun jdk15
> with
> no external XML jars). It might be good to wrap this particular test
> inside of an
>
> if (XML.classpathMeetsXMLReqs())
> ....
>
> where "XML" is junit/XML.java. I think that's all that would be needed,
> though
> I haven't actually tried it out...
>
> Army
>
>
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
Posted by Army <qo...@gmail.com>.
Daniel John Debrunner wrote:
>
> I thought there were standard apis to the Xpath engine or is that just
> for the XML parser?
It looks there's a standard API for XPath as of 1.5, encapsulated in the
javax.xml.xpath.* package. But that package does not exist for 1.4 (which is
what the initial XML support was catering to).
As for the XML parser, Yes, the standard API for that exists in 1.4 and Derby
currently uses it. That's what the "JAXP" stuff is all about. So Derby works
in any environment where it can find a JAXP parser. Xerces is the Apache parser
which satisfies the API, and Xerces is embedded within the more recent JVMs.
But it is not a requirement; a user could, for example, put the Crimson parser
in his/her classpath and Derby would still run correctly using that.
Xalan, however, is a different story. There was no Java standard XPath API when
Derby XML came out (to my knowledge...), so Derby has specific dependencies on
the Xalan package. Unlike Xerces, Xalan cannot be swapped out unless the Derby
code is itself changed.
Army
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
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Daniel John Debrunner <dj...@apache.org> writes:
> Knut Anders Hatlen wrote:
>> Daniel John Debrunner <dj...@apache.org> writes:
>>
>>> Army wrote:
>>>> Knut Anders Hatlen wrote:
>>>>> 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.
>>>> Hmm...would this me we were coding Derby for a specific JVM (or set
>>>> of JVMs)? Is that a precedence we really want to set?
>>> No. I think Sun states for their VM that applications should not use
>>> classes in the com.sun domain.
>>
>> How would com.sun.org.apache be different from com.sun.crypto,
>> com.ibm.crypto and com.sun.jndi.ldap, which all are used in the current
>> code base?
>
> Doh, I was thinking of the sun.* packages:
> http://java.sun.com/products/jdk/faq/faq-sun-packages.html
>
> Sorry.
>
> Ideally derby wouldn't have any dependency on a specific JVM vendor's
> classes, especially if there are standard classes (java[x].*) to
> perform the same functionality. One fact would be are those classes
> documented as part of the JVM implementation?
The JAXP reference implementation (https://jaxp.dev.java.net/) documents
the package names in its Compatibility Guide.
It looks like most of SqlXmlUtil could be written against java[x].*
interfaces, with the exception of the two methods (loadSerializer() and
serializeToString()) that use the Xalan classes. Since Xalan's interface
is currently not in the Java SE spec, an approach with an internal
serializer interface with the possibility for different implementations
sounds reasonable to me.
--
Knut Anders
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
Posted by Daniel John Debrunner <dj...@apache.org>.
Knut Anders Hatlen wrote:
> Daniel John Debrunner <dj...@apache.org> writes:
>
>> Army wrote:
>>> Knut Anders Hatlen wrote:
>>>> 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.
>>> Hmm...would this me we were coding Derby for a specific JVM (or set
>>> of JVMs)? Is that a precedence we really want to set?
>> No. I think Sun states for their VM that applications should not use
>> classes in the com.sun domain.
>
> How would com.sun.org.apache be different from com.sun.crypto,
> com.ibm.crypto and com.sun.jndi.ldap, which all are used in the current
> code base?
Doh, I was thinking of the sun.* packages:
http://java.sun.com/products/jdk/faq/faq-sun-packages.html
Sorry.
Ideally derby wouldn't have any dependency on a specific JVM vendor's
classes, especially if there are standard classes (java[x].*) to perform
the same functionality. One fact would be are those classes documented
as part of the JVM implementation? I guess we could probably get rid of
the com.ibm.crypto and com.sun.crypto references in Derby since the JVMs
now load the crypo stuff automatically.
Dan.
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
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Daniel John Debrunner <dj...@apache.org> writes:
> Army wrote:
>> Knut Anders Hatlen wrote:
>>>
>>> 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.
>>
>> Hmm...would this me we were coding Derby for a specific JVM (or set
>> of JVMs)? Is that a precedence we really want to set?
>
> No. I think Sun states for their VM that applications should not use
> classes in the com.sun domain.
How would com.sun.org.apache be different from com.sun.crypto,
com.ibm.crypto and com.sun.jndi.ldap, which all are used in the current
code base?
--
Knut Anders
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
Posted by Daniel John Debrunner <dj...@apache.org>.
Army wrote:
> Knut Anders Hatlen wrote:
>>
>> 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.
>
> Hmm...would this me we were coding Derby for a specific JVM (or set of
> JVMs)? Is that a precedence we really want to set?
No. I think Sun states for their VM that applications should not use
classes in the com.sun domain. Even worse come Java 7 there's a chance
that using such a class could trigger GPL (depends on details of the
classpath exception which I haven't looked at).
I thought there were standard apis to the Xpath engine or is that just
for the XML parser?
Dan.
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
Posted by Army <qo...@gmail.com>.
Knut Anders Hatlen wrote:
>
> 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.
Hmm...would this me we were coding Derby for a specific JVM (or set of JVMs)?
Is that a precedence we really want to set? Sure, it's Sun's JVM, but
still...do we do have any other specific logic in the Derby code?
> 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.
Same question as above.
> If we require Xalan specific classes/methods and cannot only rely on
> generic interfaces, then I agree, Xalan is what we should check for.
I think this is probably the way to go.
> 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.
I think it's important to make sure we're talking about the same Jira. I think
it makes sense to file an issue for checking specifically for Xalan classes.
I'm not so sure I like the idea of adding code to check for a set of classes
that are only present in Sun jdks. That makes me a little uncomfortable...
Army
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
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Army <qo...@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
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
Posted by Army <qo...@gmail.com>.
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?
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.
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.
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...
Note that junit/XML.java relies on the same class ("org.apache.xpath.XPath") to
assume Xalan exists, as well. Hmm.
Army
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
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Army <qo...@gmail.com> writes:
> mamta@apache.org wrote:
>> + + s.executeUpdate("set schema APP");
>> + checkLangBasedQuery(s, "SELECT XMLSERIALIZE(x as CHAR(10)) " +
>> + " FROM xmlTable, SYS.SYSTABLES WHERE " + +
>> " XMLSERIALIZE(x as CHAR(10)) = TABLENAME",
>> + null);
>
> Just for the record, I think use of XMLSERIALIZE here will fail if the
> test classpath does not include the required Xalan/JAXP classes
> (ex. Sun jdk15 with no external XML jars). It might be good to wrap
> this particular test inside of an
>
> if (XML.classpathMeetsXMLReqs())
> ....
>
> where "XML" is junit/XML.java. I think that's all that would be
> needed, though I haven't actually tried it out...
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?
--
Knut Anders