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 David Van Couvering <Da...@Sun.COM> on 2006/08/05 02:28:23 UTC
Need help with XML patches (was Re: last week of 10.2 development)
I changed the subject to see if this might get the attention of those
otherwise deleting the thread. I am heads down on the copyright stuff
and don't know either SQL/XML or the compiler that well, so I'm not sure
I'm the right person to do the reviewing.
However, if someone else wants to do the reviews, I'm happy to apply the
patch, run tests in the background while running license header scripts,
and commit.
Army, do your patches include necessary release notes/documentation?
David
Army wrote:
> Kathey Marsden wrote:
>> Rick Hillegas wrote:
>>
>>> We are headed into the last week of 10.2 development. A number of
>>> Blocker and Urgent issues are still in motion. Now would be a good
>>> time to alert the community if you are working on one of these issues
>>> and think that you might need some help to finish by August 10.
>>
>> DERBY-688 Enhancements to XML functionality to move toward
>> XPath/XQuery support...
>> http://issues.apache.org/jira/browse/DERBY-688
>
>
> There are currently 5 (yes, five) incremental patches attached to
> DERBY-688, each of which is dependent on its predecessor and none of
> which have been reviewed/committed yet. I also have one or two
> _additional_ (small) patches to post in order to align the XML datatype
> with the targeted subset of SQL/XML[2006] functionality.
>
> I've already given up on completing any of the JDBC-side changes
> described for DERBY-688 by the August 10th deadline (yes, I need to
> update the spec to reflect that); instead I'm just working on SQL-side
> support only (and even that is just a subset of what I originally
> proposed). That said, I've been side-tracked with the blocker
> regression DERBY-1633 and am therefore quickly running out of time to
> finish the final XML changes.
>
> While I still hope to have the remaining patches posted by the 10th, if
> anyone has time to review/commit the patches that I've already posted, I
> would be extremely grateful. It's hard enough that I'm side-tracked
> with DERBY-1633; it would be nice if, when I finally get back to XML, I
> could just spend time on the remaining changes instead of having to
> re-sync all five patches with the latest codeline (and with each other)
> and then create the final patches w.r.t to those other uncommitted
> patches. Ugh. This kind of multi-patch-sync is time-consuming,
> error-prone, and just generally not fun (one of the downsides to
> incremental development, I guess...?).
>
> If there's anyone out there with the time and inclination to move the
> XML patches forward (by reviewing and/or commmitting), I could certainly
> use the help.
>
> Many thanks,
> Army
>
Re: Need help with XML patches (was Re: last week of 10.2 development)
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Yip Ng wrote:
> Got my attention. I am almost done with my other jira issues so I can
> help review Army's XML patches. =)
Thanks, Yip!
I, too, am hoping to spend some time over the next few days reviewing
Army's patches. Learning about this work has been on my list for a while,
so I'm glad to get nudged.
bryan
Re: Need help with XML patches (was Re: last week of 10.2 development)
Posted by Yip Ng <yi...@gmail.com>.
Got my attention. I am almost done with my other jira issues so I can help
review Army's
XML patches. =)
Yip
On 8/4/06, David Van Couvering <Da...@sun.com> wrote:
>
> I changed the subject to see if this might get the attention of those
> otherwise deleting the thread. I am heads down on the copyright stuff
> and don't know either SQL/XML or the compiler that well, so I'm not sure
> I'm the right person to do the reviewing.
>
> However, if someone else wants to do the reviews, I'm happy to apply the
> patch, run tests in the background while running license header scripts,
> and commit.
>
> Army, do your patches include necessary release notes/documentation?
>
> David
>
> Army wrote:
> > Kathey Marsden wrote:
> >> Rick Hillegas wrote:
> >>
> >>> We are headed into the last week of 10.2 development. A number of
> >>> Blocker and Urgent issues are still in motion. Now would be a good
> >>> time to alert the community if you are working on one of these issues
> >>> and think that you might need some help to finish by August 10.
> >>
> >> DERBY-688 Enhancements to XML functionality to move toward
> >> XPath/XQuery support...
> >> http://issues.apache.org/jira/browse/DERBY-688
> >
> >
> > There are currently 5 (yes, five) incremental patches attached to
> > DERBY-688, each of which is dependent on its predecessor and none of
> > which have been reviewed/committed yet. I also have one or two
> > _additional_ (small) patches to post in order to align the XML datatype
> > with the targeted subset of SQL/XML[2006] functionality.
> >
> > I've already given up on completing any of the JDBC-side changes
> > described for DERBY-688 by the August 10th deadline (yes, I need to
> > update the spec to reflect that); instead I'm just working on SQL-side
> > support only (and even that is just a subset of what I originally
> > proposed). That said, I've been side-tracked with the blocker
> > regression DERBY-1633 and am therefore quickly running out of time to
> > finish the final XML changes.
> >
> > While I still hope to have the remaining patches posted by the 10th, if
> > anyone has time to review/commit the patches that I've already posted, I
> > would be extremely grateful. It's hard enough that I'm side-tracked
> > with DERBY-1633; it would be nice if, when I finally get back to XML, I
> > could just spend time on the remaining changes instead of having to
> > re-sync all five patches with the latest codeline (and with each other)
> > and then create the final patches w.r.t to those other uncommitted
> > patches. Ugh. This kind of multi-patch-sync is time-consuming,
> > error-prone, and just generally not fun (one of the downsides to
> > incremental development, I guess...?).
> >
> > If there's anyone out there with the time and inclination to move the
> > XML patches forward (by reviewing and/or commmitting), I could certainly
> > use the help.
> >
> > Many thanks,
> > Army
> >
>
Re: DERBY-688: Is this a build problem? a CLASSPATH problem? a security
problem?
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> with a newer version (I'm using 2.6), the problem goes away.
>
> Does this solve the problem for you?
Hi Army,
Yes, switching to Xalan 2.7 and installing it as an "endorsed standard"
in my JRE does indeed make the problem go away, and xml_general.sql
now passes for me.
Thanks for the quick response!
I'll continue with my review, and try to get my comments to you by
the end of the weekend.
thanks,
bryan
Re: DERBY-688: Is this a build problem? a CLASSPATH problem? a security
problem?
Posted by Suresh Thalamati <su...@gmail.com>.
Army wrote:
> Bryan Pendleton wrote:
>
>> Hi Army,
>>
<snip ..>
> If you are just using the version that is part of Sun jdk 1.4.2, then I
> think there is a bug in that version of Xalan that is causing this
> error. I think it's related to XALANJ-1643 (type that in your Jira
> "Quick Search" box) and has been fixed in Xalan version 2.5 and later
> (based on the comments in that issue).
>
> When I removed my external version of Xalan and just ran with the one
> that's embedded in Sun 1.4.2, I see this error, too. When I take the
> steps to override the jdk's version (which is a bit odd; see:
>
> http://xml.apache.org/xalan-j/faq.html#faq-N100D6)
>
> with a newer version (I'm using 2.6), the problem goes away.
>
>
Hi Army,
I ran into the same issue when I tried to run lang/xmlBinding.java,
in my first attempt to learn about xml work in derby as part of buddy
testing!
I ran the test using jdk142, with xml jars added to my class path. It
passed on ibm142.
Error Messages were scary :
java.lang.ExceptionInInitializerError
> Caused by: java.lang.RuntimeException: The resource [
XMLEntities.res ] could
not load: java.net.MalformedURLException: no protocol: XMLEntities.res
> XMLEntities.res java.net.MalformedURLException: no protocol:
XMLEntitie
and later my favorite error :
> ERROR 40XT0: An internal error was identified by RawStore module.
From the above error message, it is almost impossible for some one to
identify that the error is because of a xalan bug(XALANJ-1643)
included in the jvm jar files.
I think, it might be good idea to mention this tricky issue in the
release notes/faq.
Thanks
-suresh
Re: DERBY-688: Is this a build problem? a CLASSPATH problem? a security
problem?
Posted by Army <qo...@gmail.com>.
Bryan Pendleton wrote:
> Hi Army,
>
> I believe I've successfully applied the XML patches in
> DERBY-688 and built them using the normal build techniques
> that I use for Derby.
>
> When I try to run, I see the exception below.
>
> org.apache.xml.utils.WrappedRuntimeException: The resource [
> file:////org/apache/xalan/serialize/XMLEntities.res ] could not load:
> java.security.AccessControlException: access denied
Can I ask what version of Xalan you are using? You should be able to figure
this out by following the directions here:
http://xml.apache.org/xalan-j/faq.html#environmentcheck
If you are just using the version that is part of Sun jdk 1.4.2, then I think
there is a bug in that version of Xalan that is causing this error. I think
it's related to XALANJ-1643 (type that in your Jira "Quick Search" box) and has
been fixed in Xalan version 2.5 and later (based on the comments in that issue).
When I removed my external version of Xalan and just ran with the one that's
embedded in Sun 1.4.2, I see this error, too. When I take the steps to override
the jdk's version (which is a bit odd; see:
http://xml.apache.org/xalan-j/faq.html#faq-N100D6)
with a newer version (I'm using 2.6), the problem goes away.
Does this solve the problem for you?
Thanks for bringing this up--I guess we are either going to have to document
that Xalan 2.5 (or whatever the specific version is) is required in order for
this to work, or else I'm going to have to figure out an alternative. But that
said, I think this is just an issue when running with SecurityManager; I tried
to run some of the SQL/XML statements in the tests manually and they all worked;
my manual tests did not use the SecurityManager.
Please let me know if the above solution works for you, or if you have any other
problems. Thanks for trying this out and for your patience as we track this down...
Army
DERBY-688: Is this a build problem? a CLASSPATH problem? a security
problem?
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Hi Army,
I believe I've successfully applied the XML patches in
DERBY-688 and built them using the normal build techniques
that I use for Derby.
When I try to run, I see the exception below.
Does this indicate that I missed out a step in building somewhere?
Can you identify what failed to build, and how to correct it?
Or, does this indicate some sort of CLASSPATH problem? Were there
CLASSPATH instructions in your notes that I missed?
Or do we possibly need to change derby_tests.policy somehow?
It's not a message I've seen before; I'm hoping it jumps right out at
you and is simple to identify.
If it's important, this came from trying to run one of your tests,
which I did by:
java org.a.dT.fT.h.RunTest lang/xml_general.sql
I'm running with Sun JDK 1.4.2 on Linux.
"jar tf $JAVA_HOME/jre/lib/rt.jar | grep -i XMLEntities"
reports that such a file *does* exist in my rt.jar
It didn't seem to matter whether or not I explicitly put a copy
of xalan.jar into my classpath prior to running the test.
thanks,
bryan
org.apache.xml.utils.WrappedRuntimeException: The resource [ file:////org/apache/xalan/serialize/XMLEntities.res ] could not load:
java.security.AccessControlException: access denied (java.io.FilePermission /org/apache/xalan/serialize/XMLEntities.res read)
file:////org/apache/xalan/serialize/XMLEntities.res java.security.AccessControlException: access denied
(java.io.FilePermission /org/apache/xalan/serialize/XMLEntities.res read)
at org.apache.xalan.serialize.SerializerFactory.getSerializer(SerializerFactory.java:142)
at org.apache.derby.iapi.types.SqlXmlUtil.loadSerializer(SqlXmlUtil.java:482)
at org.apache.derby.iapi.types.SqlXmlUtil.<init>(SqlXmlUtil.java:166)
at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindXMLParse(UnaryOperatorNode.java:403)
at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindUnaryOperator(UnaryOperatorNode.java:363)
at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindExpression(UnaryOperatorNode.java:321)
at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindUnaryOperator(UnaryOperatorNode.java:346)
at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindExpression(UnaryOperatorNode.java:321)
at org.apache.derby.impl.sql.compile.ResultColumn.bindExpression(ResultColumn.java:579)
at org.apache.derby.impl.sql.compile.ResultColumnList.bindExpressions(ResultColumnList.java:558)
at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:526)
at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(DMLStatementNode.java:248)
at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java:161)
at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java:252)
at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:344)
at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:118)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:713)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:567)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516)
at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:313)
at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:478)
at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:347)
at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:248)
at org.apache.derby.impl.tools.ij.Main.go(Main.java:203)
at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169)
at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
at org.apache.derby.tools.ij.main(ij.java:69)
Re: Need help with XML patches (was Re: last week of 10.2 development)
Posted by Army <qo...@gmail.com>.
David Van Couvering wrote:
> I changed the subject to see if this might get the attention of those
> otherwise deleting the thread.
Thanks David! Looks like it worked :)
And thanks to Yip and Bryan for offering to start the review process. I do
appreciate your time and any feedback you might have.
> Army, do your patches include necessary release notes/documentation?
I don't think 'release notes' are needed per se since, up until now, XML has
been an "experimental" development that has not been documented anywhere
official (because SQL/XML standard was still evolving and thus we couldn't
guarantee any specific functionality). There are also notes in DERBY-334, which
is where the XML type was first introduced, saying that the XML datatype was not
intended for production use due to evolving standards. So theoretically no
users should be using the XML datatype in their environments (famous last words?)
As for documentation, I've scanned through the Derby manuals and composed what I
believe to be the necessary doc additions for the XML type; still need to file a
Jira issue for that and attach my proposed changes. It's on my list...
Thanks again to all who have graciously offered to review, commit, and/or
provide feedback on the patches.
Army