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 "Myrna van Lunteren (JIRA)" <ji...@apache.org> on 2007/01/28 20:54:49 UTC
[jira] Updated: (DERBY-2269) running tests (derbyall, or
suites.All) with weme6.1 (or wctme5.7) with derbyrun.jar fails with
NoClassDefFoundError: javax.naming.Referenceable
[ https://issues.apache.org/jira/browse/DERBY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren updated DERBY-2269:
--------------------------------------
Attachment: DERBY-2269_b.diff
DERBY-2269_a.diff
I'm attaching two possible approaches to prevent this.
DERBY-2269_a.diff basically adds back the catch NoClassDefFoundError that used to happen before change 492822.
DERBY-2269_b.diff puts an if !JDBC.vmSupportsJSR169() block around the getURL("org.apache.derby.jdbc.ClientDataSource") which was resulting in loading of javax.naming.Referenceable down the line.
I'd like input on which approach is preferable.
Once I get that, I'll (re)run derbyall & suites.All. If I don't get any input, I'll go with approach b.
> running tests (derbyall, or suites.All) with weme6.1 (or wctme5.7) with derbyrun.jar fails with NoClassDefFoundError: javax.naming.Referenceable
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2269
> URL: https://issues.apache.org/jira/browse/DERBY-2269
> Project: Derby
> Issue Type: Bug
> Environment: weme 6.1.(.1) or wctme5.7 (foundation)
> Reporter: Myrna van Lunteren
> Assigned To: Myrna van Lunteren
> Priority: Minor
> Attachments: DERBY-2269_a.diff, DERBY-2269_b.diff
>
>
> When running any of the tests (e.g.
> j9 org.apache.derbyTesting.functionTests.harness.RunTest lang/supersimple.sql
> or
> j9 [-Dclienthost...-Dserverhost...] junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.tools._Suite)
> with j9 and derbyrun.jar in the classpath, the tests (most - actually 5 tests out of derbyall will pass) will bail out, and no results will be returned. The stack trace (from RunTest lang/supersimple) is like this:
> ------------------------------
> Exception in thread "main" java.lang.NoClassDefFoundError: javax.naming.Referenceable
> at java.lang.ClassLoader.defineClassImpl(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:226)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:109)
> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1029)
> at java.net.URLClassLoader.findInExtensions(URLClassLoader.java:328)
> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1038)
> at java.net.URLClassLoader$4.run(URLClassLoader.java:549)
> at java.security.AccessController.doPrivileged(AccessController.java:213)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:547)
> at com.ibm.oti.vm.URLSystemClassLoader.findClass(URLSystemClassLoader.java:27)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:606)
> at com.ibm.oti.vm.URLSystemClassLoader.loadClass(URLSystemClassLoader.java:60)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.lang.ClassLoader.defineClassImpl(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:226)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:109)
> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1029)
> at java.net.URLClassLoader.findInExtensions(URLClassLoader.java:328)
> at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1038)
> at java.net.URLClassLoader$4.run(URLClassLoader.java:549)
> at java.security.AccessController.doPrivileged(AccessController.java:213)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:547)
> at com.ibm.oti.vm.URLSystemClassLoader.findClass(URLSystemClassLoader.java:27)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:606)
> at com.ibm.oti.vm.URLSystemClassLoader.loadClass(URLSystemClassLoader.java:60)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:114)
> at org.apache.derbyTesting.junit.SecurityManagerSetup.getURL(SecurityManagerSetup.java:318)
> at org.apache.derbyTesting.junit.SecurityManagerSetup.determineClasspath(SecurityManagerSetup.java:280)
> at org.apache.derbyTesting.junit.SecurityManagerSetup.<clinit>(SecurityManagerSetup.java:57)
> at java.lang.J9VMInternals.initializeImpl(Native Method)
> at java.lang.J9VMInternals.initialize(J9VMInternals.java:177)
> at org.apache.derbyTesting.functionTests.harness.jvm.getSecurityProps(jvm.java:385)
> at org.apache.derbyTesting.functionTests.harness.jvm.setSecurityProps(jvm.java:345)
> at org.apache.derbyTesting.functionTests.harness.RunTest.buildTestCommand(RunTest.java:2350)
> at org.apache.derbyTesting.functionTests.harness.RunTest.testRun(RunTest.java:498)
> at org.apache.derbyTesting.functionTests.harness.RunTest.main(RunTest.java:368)
> ------------------------
> I had been tracking down a similar problem when derbynet.jar is in the classpath, but derbynet.jar should not be in the classpath when running with this jvm, so that was irritating but understandable.
> But, to note, I had tracked that (new to me when I first noticed it about a week ago) failure down to probably related to a change in junit.SecurityManagerSetup.java with revision 492822, which changed the error to be caught with derbynet.jar/derbyclient.jar from NoClassDefFoundError to the more logical ClassNotFoundException.
> Possibly this issue was exposed by the same change.
> Not sure what the solution is yet.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.