The following error has not been a particularly satisfactory answer on Google, and later saw an article about the JUnit class loader BUG, finally thinking that Liu is dark.
java.lang.LinkageError: Class org / w3c / dom / Document violates loader constraints atjava.lang.ClassLoader.defineClass0 (Native Method) at java.lang.ClassLoader.defineClass (ClassLoader.java:502) at java.lang.ClassLoader. DefineClass (ClassLoader.java: 431) AT .......
Such an exception is mainly due to the non-systematic class loader, that is, the custom class loader has problems, this class loader tries to load org.w3c.dom.Document, then if the class loader does not process correctly, Or the Document class is not in JVM's System Classpath, the class loader can not load, you can't load itself, nor notified the system class loader, the above error will appear. . .
It may be understood that there is a problem, please refer to the article below, I tried it, completely credible:
JUnit ClassLoader Proposed Fix
Here's a patch for JUnit's busted classloader:. Junit-patch.jar And below is XmlTest.java, a regression test that breaks (with a java.lang.LinkageError) with the old classloader and the swingui / awtui TestRunners, but passes with the Patch. junit-patch.jar Contains Two classes: Source Included:
ReloadableTestClassLoader - a properly delegating custom ClassLoader that currently relies on a System property value for its classpath:. Junit.test.path The fix can be ported to junit.runner.TestCaseClassLoader or it can be effected through a new ClassLoader like this one ReloadingTestSuiteLoader. - modified to return this custom ClassLoader If I can get this fix applied to the real JUnit, this class would not necessarily need to be modified (it's only like 5 lines) because we could fix the original TestCaseClassLoader instead of writing a new one. ..........................
Import javax.xml.parsers. *;
Import org.w3c.dom.document;
Import Org.w3c.dom.Element;
Public class xmltest extends testcase {
Document doc = null; public void testXML () throws ParserConfigurationException {
Doc = documentbuilderfactory.newinstance () .newdocumentBuilder () .newdocument ();
// system.out.println ("Hello! I Changd Again);
Element root = doc.createElement ("XML-Test");
askERTNOTNULL (root);
}
} This is a Simple Test Test That Reproduces A LinkageError With The Junit Buggy ClassLoader Under The Following Conditions:
Use Sun JDK 1.4.x Edit JUnit's excluded.properties so that you comment out the exclusion of org.w3c.dom * -.. This is necessary to reveal the bug and is the easiest test I could think of Make sure your edited excluded .properties is first in the classpath or updated into junit.jar at junit / runner / excluded.properties (BTW, obviously the new ReloadableTestClassLoader does not use or rely on excluded.properties at all). Put the DOM interfaces (in Xerces these are in xml-apis.jar) and an XML parser impl, such as Xerces, in your classpath to reproduce the bug. Why? Since you will have unexcluded org.w3c.dom. * in excluded.properties, JUnit will attempt to load those interfaces rather than delegate to the system loader. But they are not in the scope of JUnit's buggy classloader if they are not in the JVM's system classpath, so you have to add them. Ie, the 1.4.x JVM loads these in ITS Boot Loader, Whose ClassPath Junit's Buggy Loader Doesn't Know About. EXAMPLE OF Command Line to Use to Reprodu CE the bug (Using Junit.jar from Junit 3.8.1): junit.jar; XML-Apis.jar; Xerces.jar Junit.Swingui.Testrunner Xmltest You Should See THIS in The Runner's Error Display Window: Java.lang.LinkageError: Class ORG / W3C / DOM / DOCUMENT VIOLATES LOADER CONSTRAINTS Atjava.lang.classLoader.defineClass0 (Native Method) AT
Java.lang.classloader.defineclass (ClassLoader.java: 502) AT
Java.lang.classloader.defineclass (ClassLoader.java: 431) AT
JUnit.Runner.TestcaseClassLoader.LoadClass (TestcaseClassLoader.java: 104) AT
Java.lang.classloader.LoadClass (ClassLoader.java:255) AT
Java.lang.classloader.LoadClassInternal (ClassLoader.java: 315) AT
Xmltest.TestXML (Xmltest.java: 16) AT
Sun.Reflect.nativeMethodaccessorImpl.invoke0 (Native Method) atsun.reflect.nativeMethodAccessorImpl.invoke (NativeMethodaccessorImpl.java: 39) AT
Sun.Reflect.DelegatingMethodaccessorImpl.invoke (DelegatingMethodaccessorImpl.java:25) AT
Java.Lang.Reflect.Method.Invoke (Method.java: 324) AT
JUnit.framework.testcase.runtest (Testcase.java: 154) AT
JUnit.framework.testcase.runbare (Testcase.java: 127) AT
JUnit.framework.testresult $ 1.Protect (TestResult.java: 106) AT
JUnit.framework.testresult.runprotected (TestResult.java: 124) AT
Junit.framework.testResult.run (TestResult.java: 109) AT
JUnit.framework.testcase.run (Testcase.java: 118) AT
JUnit.framework.testsuite.runtest (Testsuite.java: 208) AT
Junit.framework.testsuite.run (Testsuite.java: 2013) AT
JUnit.swingui.teestrunner $ 16.Run (Testrunner.java: 623) Now Run The Same Test with The Fixed ClassLoader:
shadow classes in junit.jar by listing junit-patch.jar first in the classpath set junit.test.path property to include the path to XmlTest.class run XmlTest with the Swing or AWT test runner: java -cp junit-patch.jar JUnit.jar -djunit.test.path =. junit.swingui.teestrunner XMLTest
