'org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest' failures on JVM 1.5 on trunk, 10.4 and 10.3

• Key: DERBY-3803
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Kathey Marsden
• Reporter: Ole Solberg
• Component/s: Test
• Affects Version/s: 10.3.3.1, 10.4.2.0, 10.5.1.1
• Fix Version/s: 10.3.3.1, 10.4.2.0, 10.5.1.1

Environment

JVM: Sun Microsystems Inc.
java version "1.5.0_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
Java HotSpot(TM) Server VM (build 1.5.0_14-b03 mixed mode 32-bit)

Description

Since r676008 (2008-07-11 18:01:05 MEST) regression tests on Jvm 1.5 has failed on trunk, 10.4 and 10.3 in suitesAll / org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest with

1) testXMLCasting(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)java.sql.SQLException: Table/View 'NONXTABLE' already exists in Schema 'APP'.
2) testXMLSerialize(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)java.sql.SQLException: Table/View 'VCTAB' already exists in Schema 'APP'.
3) testXMLQueryInsert(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)java.sql.SQLException: Failed to locate 'JAXP' API or implementation classes. XML operations are not permitted unless these classes are in your classpath.
4) testXMLQueryUpdate(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)java.sql.SQLException: Failed to locate 'JAXP' API or implementation classes. XML operations are not permitted unless these classes are in your classpath.
5) testAttrSerialization(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)java.sql.SQLException: Failed to locate 'JAXP' API or implementation classes. XML operations are not permitted unless these classes are in your classpath.
6) testTriggerSPSWithXML(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)java.sql.SQLException: Failed to locate 'JAXP' API or implementation classes. XML operations are not permitted unless these classes are in your classpath.
1) testNonXMLColsWithXMLVals(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:<[42821]> but was:<[XML00]>
2) testXMLParse(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:<[42X25]> but was:<[XML00]>
3) testTopLevelSelect(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:<[42Z71]> but was:<[XML00]>
4) testXMLParseSerializeCombos(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:<[2200M]> but was:<[XML00]>
5) testXMLExists(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:<[42Z77]> but was:<[XML00]>
6) testXMLQuery(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:<[42Z71]> but was:<[XML00]>
7) testNestedXMLQuery(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:<[2200V]> but was:<[XML00]>
8) testInvalidXMLBindings(org.apache.derbyTesting.functionTests.tests.lang.XMLBindingTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:<[42Z7]0> but was:<[XML0]0>

See e.g.
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-676008.html
http://dbtg.thresher.com/derby/test/10.4Branch/jvm1.5/testing/Limited/testSummary-676639.html
and
http://dbtg.thresher.com/derby/test/debug/10.3Branch_logfile_org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest.out


The failure appears to be introduced by svn r675956 (Fri Jul 11 07:07:51 PDT 2008): derby-3745_trunk_diff.txt.

Comments

[Kathey Marsden]

I verified the test passed with IBM 1.4.2, 1.5 and 1.6 with no modification of the classpath. Xalan is built in.
I verified that it passes with Sun 1.4.2 with the Xalan jars copied to the jre/lib/endorsed directory according to the instructions.
I verified that it passes with Sun 1.6 with the Xalan jars just added to the user classpath.
So, only Sun JDK 1.5 seems to have this problem. I am not yet sure why. Any ideas are welcome.

[Kathey Marsden]

Here is the trace when we get the exception that it cannot find the JAXP API or implementation classes. One interesting thing to note is that the excepton is not coming from one of the threads that was created and had its context class loader set to null. I am fairly sure whenever we set the primary thread context classloader to null we restore it immediately after creating the thread.

ERROR XML00: Failed to locate 'JAXP' API or implementation classes. XML operations are not permitted unless these classes are in your classpath.

at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)

at org.apache.derby.iapi.types.SqlXmlUtil.<init>(SqlXmlUtil.java:199)

at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindXMLParse(UnaryOperatorNode.java:390)

at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindExpression(UnaryOperatorNode.java:316)

at org.apache.derby.impl.sql.compile.ResultColumn.bindExpression(ResultColumn.java:588)

at org.apache.derby.impl.sql.compile.ResultColumnList.bindExpressions(ResultColumnList.java:693)

at org.apache.derby.impl.sql.compile.RowResultSetNode.bindExpressions(RowResultSetNode.java:238)

at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(DMLStatementNode.java:227)

at org.apache.derby.impl.sql.compile.InsertNode.bindStatement(InsertNode.java:307)

at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:314)

at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)

at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:794)

at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)

at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:175)

at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(DRDAConnThread.java:5019)

at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:750)

at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:290)


The code that causes this failure is as follows. We actually seem to lose the actual exception and assume it is because there is no JAXP implmentation. I will print out the actual exception and see if that sheds any more light.
 DocumentBuilderFactory dBF = null;
            try {

                dBF = DocumentBuilderFactory.newInstance();

            } catch (Throwable e) {

                /* We assume that if we get an error creating the
                 * DocumentBuilderFactory, it's because there's no
                 * JAXP implementation. This can happen in the
                 * (admittedly unlikely) case where the classpath
                 * contains the JAXP _interfaces_
                 * and the Xalan classes but does not actually
                 * contain a JAXP _implementation_. In that case the
                 * check in XML.checkXMLRequirements() will pass
                 * and this class (SqlXmlUtil) will be instantiated
                 * successfully--which is how we get to this constructor.
                 * But then attempts to create a DocumentBuilderFactory
                 * will fail, bringing us here. Note that we can't
                 * check for a valid JAXP implementation in the
                 * XML.checkXMLRequirements() method because we
                 * always want to allow the XML.java class to be
                 * instantiated, even if the required XML classes
                 * are not present--and that means that it (the
                 * XML class) cannot reference DocumentBuilder nor
                 * any of the JAXP classes directly.
                 */
                 throw StandardException.newException(
                     SQLState.LANG_MISSING_XML_CLASSES, "JAXP");

            }

[Kathey Marsden]

The actual exception is:
javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found
at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:104)
at org.apache.derby.iapi.types.SqlXmlUtil.<init>(SqlXmlUtil.java:175)
at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindXMLParse(UnaryOperatorNode.java:390)
at org.apache.derby.impl.sql.compile.UnaryOperatorNode.bindExpression(UnaryOperatorNode.java:316)
at org.apache.derby.impl.sql.compile.ResultColumn.bindExpression(ResultColumn.java:588)
at org.apache.derby.impl.sql.compile.ResultColumnList.bindExpressions(ResultColumnList.java:693)
at org.apache.derby.impl.sql.compile.RowResultSetNode.bindExpressions(RowResultSetNode.java:238)
at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(DMLStatementNode.java:227)
at org.apache.derby.impl.sql.compile.InsertNode.bindStatement(InsertNode.java:307)
at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:314)
at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:794)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)
at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:175)
at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(DRDAConnThread.java:5019)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:750)
at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:290)

[Kathey Marsden]

I think I found it. The getDaemonThread method is used to start the network server thread from DRDAServerStarte which should not have its context class loader nulled out. I'm working on a fix.

[Kathey Marsden]

Here is a patch for this issue. Running tests now. I took the setting of the context class loader out of getDaemonThread() and put it after the calll to getDaemonThread for the two threads that were at issue.

[Kathey Marsden]

This issue corrects the fix for DERBY-3745. So anyone picking up the fix for DERBY-3745 should pick up the fix for DERBY-3803 as well.

[Ole Solberg]

The issue is corrected on trunk, but I think it should also be merged to 10.4 where it is still present:
http://dbtg.thresher.com/derby/test/10.4Branch/jvm1.5/testing/Limited/

[Kathey Marsden]

Thanks Ole, I was just waiting for results on trunk before backporting to 10.4 and 10.3 which I will do today.

Kathey

[Rick Hillegas]

Assign to 10.4.2 release vehicle.