db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2701) many sealing violation errors in ibm142 and ibm15 jvm test runs of junit tests.
Date Sat, 26 May 2007 20:21:16 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mike Matrigali updated DERBY-2701:

>From doing builds it looks like the following change caused the derbytools.jar bloat.
 Again I have no idea if the change is wrong, or if the change just added new requirements
to the tools that build the jar files:
r541435 | kahatlen | 2007-05-24 14:21:27 -0700 (Thu, 24 May 2007) | 37 lines

DERBY-1440: jdk 1.6 client driver omits SQLStates and chained exceptions in
error messages

While working on DERBY-2472 I found out what caused this difference between
the JDBC 3.0 driver and the JDBC 4.0 driver. There are three
problems. Firstly, StandardException.unexpectedUserException() doesn't
recognize that an SQLException is generated Derby since it is not an
EmbedSQLException. Secondly, TransactionResourceImpl.wrapInSQLException()
invokes SQLException.setNextException() explicitly so that the required
chaining/ferrying logic in the exception factory and in EmbedSQLException's
constructor is not used. Thirdly,
SQLException40.wrapArgsForTransportAcrossDRDA() puts a standard
SQLException, not an EmbedSQLException, in the argument ferry's
next-exception chain, which prevents the network server from seeing it as a
Derby exception.

The attached patch fixes the problem by

  1) using SQLExceptionFactory.getArgumentFerry() to find out whether the
     exception is a Derby exception in unexpectedUserException()

  2) using factory methods instead of setNextException() to do the chaining
     in wrapInSQLException()

  3) improving Util.javaException() so that it sets up a next-exception
     chain if the Java exception contains nested exceptions

  4) changing wrapArgsForTransportAcrossDRDA() to create an argument ferry
     whose next exception is the argument ferry of the main exception's next

This patch also fixes all the JUnit tests that contain code looking like this:

    assertStatementError(JDBC.vmSupportsJDBC4() ? "38000" : "42X62", cSt);

Now, the check for JDBC level is not needed anymore for those tests.


U  java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java
U  java\engine\org\apache\derby\impl\jdbc\SQLExceptionFactory40.java
U  java\engine\org\apache\derby\impl\jdbc\Util.java
U  java\engine\org\apache\derby\impl\jdbc\TransactionResourceImpl.java
U  java\engine\org\apache\derby\iapi\error\StandardException.java
U  java\engine\org\apache\derby\jdbc\EmbedXAResource.java
U  java\testing\org\apache\derbyTesting\functionTests\tests\lang\XMLTypeAndOpsTest.java
U  java\testing\org\apache\derbyTesting\functionTests\tests\lang\SysDiagVTIMappingTest.java
U  java\testing\org\apache\derbyTesting\functionTests\tests\lang\ProcedureInTriggerTest.java
U  java\testing\org\apache\derbyTesting\functionTests\tests\tools\ImportExportLobTest.java
U  java\testing\org\apache\derbyTesting\functionTests\tests\tools\ImportExportBinaryDataTest.java
U  java\testing\org\apache\derbyTesting\functionTests\tests\tools\ImportExportTest.java
Updated to revision 541410.

> many sealing violation errors in ibm142 and ibm15 jvm test runs of junit tests.
> -------------------------------------------------------------------------------
>                 Key: DERBY-2701
>                 URL: https://issues.apache.org/jira/browse/DERBY-2701
>             Project: Derby
>          Issue Type: Bug
>          Components: Build tools, Regression Test Failure
>    Affects Versions:
>         Environment: am seeing the sealing errors on windows, under ibm15 and ibm142
>            Reporter: Mike Matrigali
>            Priority: Blocker
>         Attachments: derbytools_build541131.jar.out, derbytools_build541503.jar.out
> The regression runs against the ibm jvms for the past 2 days are seeing 390 errors which
I think the majority are coming from this sealing error.
> I am trying to figure out if this is a build/testing machine problem or a real problem
introduced by thursday night checkins which included:
> 541131 TO 541503:
> I ran in my own client against classes and ibm15 and passed the junit suite.  
> see:
> http://people.apache.org/~fuzzylogic/derby_test_results/main/testlog/ibm142/541503-suites.All_diff.txt
> http://people.apache.org/~fuzzylogic/derby_test_results/main/testlog/ibm15/541503-suites.All_diff.txt
> 1) PrepareStatementTest:embeddedjava.lang.ExceptionInInitializerError
> 	at java.lang.Class.forName1(Native Method)
> 	at java.lang.Class.forName(Class.java:180)
> 	at org.apache.derbyTesting.junit.DriverManagerConnector.loadJDBCDriver(DriverManagerConnector.java:143)
> 	at org.apache.derbyTesting.junit.DriverManagerConnector.openConnection(DriverManagerConnector.java:72)
> 	at org.apache.derbyTesting.junit.DriverManagerConnector.openConnection(DriverManagerConnector.java:43)
> 	at org.apache.derbyTesting.junit.TestConfiguration.openDefaultConnection(TestConfiguration.java:957)
> 	at org.apache.derbyTesting.junit.BaseJDBCTestSetup.getConnection(BaseJDBCTestSetup.java:74)
> 	at org.apache.derbyTesting.junit.CleanDatabaseTestSetup.setUp(CleanDatabaseTestSetup.java:65)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> Caused by: java.lang.SecurityException: sealing violation: can't seal package org.apache.derby.iapi.services.io:
already loaded
> 	at java.net.URLClassLoader.defineClass(URLClassLoader.java:412)
> 	at java.net.URLClassLoader.access$500(URLClassLoader.java:109)
> 	at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:848)
> 	at java.security.AccessController.doPrivileged1(Native Method)
> 	at java.security.AccessController.doPrivileged(AccessController.java:389)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:371)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:570)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:442)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:502)
> 	at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source)
> 	at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source)
> 	at org.apache.derby.jdbc.EmbeddedDriver.<clinit>(Unknown Source)
> 	... 23 more

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message