Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 18499 invoked from network); 14 May 2007 17:38:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 May 2007 17:38:38 -0000 Received: (qmail 72915 invoked by uid 500); 14 May 2007 17:38:43 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 72882 invoked by uid 500); 14 May 2007 17:38:43 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 72873 invoked by uid 99); 14 May 2007 17:38:43 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 May 2007 10:38:43 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 May 2007 10:38:36 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 67D4B714041 for ; Mon, 14 May 2007 10:38:16 -0700 (PDT) Message-ID: <18522361.1179164296411.JavaMail.jira@brutus> Date: Mon, 14 May 2007 10:38:16 -0700 (PDT) From: "Myrna van Lunteren (JIRA)" To: derby-dev@db.apache.org Subject: [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 In-Reply-To: <6684935.1169686369056.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren updated DERBY-2269: -------------------------------------- Component/s: Test > 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 > Components: Test > Environment: weme 6.1.(.1) or wctme5.7 (foundation) > Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren > Priority: Minor > Fix For: 10.3.0.0 > > 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.(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.