unable to run spring/jpa/dao test with derby starting with surefire 2.4.x

Dan Fabulich added a comment - 09/Feb/08 6:42 PM I can't reproduce this; I think I need more environment information. When I run this test, no matter whether I use Surefire 2.3.1 or 2.4.1, I get a failure in ConfigDaoTest.testConfigDao, shown below. Maven version: 2.0.8 Java version: 1.5.0_12 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" testConfigDao(com.mycomp.mytest.ConfigDaoTest) Time elapsed: 0.391 sec <<< ERROR! org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 15 in XML document from class path resource [com/mycomp/applicationContext-mytest-persistence.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'aop:aspectj-autoproxy'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'aop:aspectj-autoproxy'. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:236) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:172) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:382) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:316) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:429) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3185) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1955) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.emptyElement(XMLSchemaValidator.java:725) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:322) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1693) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:250) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:292) at org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:76) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:351) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:303) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:280) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:131) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:147) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:173) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.springframework.test.jpa.AbstractJpaTests.runBare(AbstractJpaTests.java:209) 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:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)

Dan Tran added a comment - 10/Feb/08 2:27 AM one more try, this time i fix up the pom and make sure it is reproducable with a clean local repo. See the second attachement

Dan Fabulich added a comment - 11/Feb/08 12:30 PM Repro'd.

Dan Fabulich added a comment - 11/Feb/08 1:07 PM The problem with this test has to do with the useSystemClassLoader configuration parameter. When I use Surefire 2.4.1 and -Dsurefire.useSystemClassLoader=false, the test passes; with =true (the default), the test fails. One of the changes from Surefire 2.3 and Surefire 2.4 was to make useSystemClassLoader=true the default; previously the default was false. "useSystemClassLoader" sounds fancy, but it's really just the normal default way of launching java: your classes and dependencies are added to the classpath in an ordinary way. When we don't use the system classloader, we do fancy stuff with "isolated" custom classloaders; this frequently had a destabilizing effect on the classes as they attempted to access the system classloader using java.lang.ClassLoader.getSystemClassLoader(). There are a bunch of bugs marked "Won't Fix" for 2.3 because the workaround is just to set useSystemClassLoader=true. Since the system classloader mechanism is the "normal" way of launching code, we have to wonder: why does this test fail when launched in the "ordinary" way, but pass when launched in a special isolated classloader? I have no idea why, and I think it's beyond me to find out. There's more than a dozen dependencies in this project and a lot of tricky interactions possible between spring, hibernate, derby, and aspectj; to figure out what's wrong would require a way more detailed debugging effort than I'm prepared to do right now. For now, I'm going to have to mark this "Won't Fix", there's a reasonable workaround available (useSystemClassLoader=false) and because I believe the current default behavior is the right choice (the default can't satisfy everyone). If there's something else we can do besides changing the default setting, I'd be curious to know of it; in that case, feel free to reopen this bug or file a new one.

Dan Tran added a comment - 11/Feb/08 2:37 PM fair enough and useSystemClassLoader=false solves my problem. Thank you put putting your valulable time for this issue.