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 Bryan Pendleton <bp...@amberpoint.com> on 2006/08/05 17:59:37 UTC

DERBY-688: Is this a build problem? a CLASSPATH problem? a security problem?

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