BPEL test case failures on Linux, was: Re: BPEL Implementation: Latest changes mean no need for deploy.xml !!
I'm seeing the same issue with:
java version 1.6.0_06
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)
Maven version: 2.0.9
Java version: 1.6.0_06
OS name: linux version: 2.6.18-8.el5 arch: i386 Family: unix
Redhat Enterprise 5.x
Thanks,
Raymond
--
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
Sent: Tuesday, May 27, 2008 7:12 PM
To: tuscany-dev@ws.apache.org
Subject: Re: BPEL Implementation: Latest changes mean no need for deploy.xml
!!
Mike Edwards wrote:
Luciano Resende wrote:
Very good news Mike !!! I hope to start working on the db issues as
soon as I get some free cycles.
Luciano,
There is something that you might be able to help me with right away.
I am running into intermittent problems with transactions in the
registration of a BPEL process with the ODE server. The transaction
causing the problem seems to be the one in the BPELImplementationProvider
start() method.
What is this transaction for?
try {
txMgr.begin();
odeServer.registerTuscanyRuntimeComponent(implementation.getProcess(),
component);
odeServer.deploy(new ODEDeployment(deploymentDir), implementation );
txMgr.commit();
} catch (Exception e) {
e.printStackTrace();
txMgr.rollback();
}
Will it cause a problem if I remove this transaction? To me it does not
seem to provide any value when the Process is being supplied by Tuscany.
I can't see any requirement for it in the ODE documentation.
Yours, Mike.
Rebuiling from scratch gives me the error below. Anybody else seeing this?
Could it be related to the transaction problem discussed here?
Running helloworld.BPELHelloWorldTestCase
org.apache.tuscany.sca.implementation.bpel.ode.ODEDeploymentException:
DEPLOY: Unexpected exception: Error reloading compiled process
{http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1;
the file appears to be corrupted.
at
org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.deploy(EmbeddedODEServer.java:285)
at
org.apache.tuscany.sca.implementation.bpel.provider.BPELImplementationProvider.start(BPELImplementationProvider.java:100)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:631)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:245)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
helloworld.BPELHelloWorldTestCase.setUp(BPELHelloWorldTestCase.java:42)
at junit.framework.TestCase.runBare(TestCase.java:125)
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
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
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:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
Caused by: org.apache.ode.bpel.iapi.BpelEngineException: Error reloading
compiled process
{http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1;
the file appears to be corrupted.
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.doHydrate(BpelProcess.java:689)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch.access$100(BpelProcess.java:654)
at
org.apache.ode.bpel.engine.BpelProcess$HydrationLatch$2.run(BpelProcess.java:666)
at
org.apache.ode.bpel.engine.NStateLatch.latch(NStateLatch.java:89)
at
org.apache.ode.bpel.engine.BpelProcess.hydrate(BpelProcess.java:547)
at
Re: BPEL test case failures on Linux - understand problem working a fix
Folks,
Apologies.
This looks like a Windows vs Linux problem associated with case sensitivity of filenames on Linux
not present on Windows.
Basically, the CBP file written to disk by the ODE processing is helloworld.cbp but a search is
made for a file HelloWorld.cbp. On Windows, this is no problem, on Linux it matters a lot.
I'm working a fix now
Yours, Mike.
PS If anyone understands the transaction failures stuff, I'll be grateful - it appears I am the only
person who is seeing these, so presumably it is a config problem with my machine
Raymond Feng wrote:
I'm seeing the same issue with:
java version 1.6.0_06
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)
Maven version: 2.0.9
Java version: 1.6.0_06
OS name: linux version: 2.6.18-8.el5 arch: i386 Family: unix
Redhat Enterprise 5.x
Thanks,
Raymond
--
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
Sent: Tuesday, May 27, 2008 7:12 PM
To: tuscany-dev@ws.apache.org
Subject: Re: BPEL Implementation: Latest changes mean no need for
deploy.xml !!
Mike Edwards wrote:
Luciano Resende wrote:
Very good news Mike !!! I hope to start working on the db issues as
soon as I get some free cycles.
Luciano,
There is something that you might be able to help me with right away.
I am running into intermittent problems with transactions in the
registration of a BPEL process with the ODE server. The transaction
causing the problem seems to be the one in the
BPELImplementationProvider start() method.
What is this transaction for?
try {
txMgr.begin();
odeServer.registerTuscanyRuntimeComponent(implementation.getProcess(),
component);
odeServer.deploy(new ODEDeployment(deploymentDir), implementation );
txMgr.commit();
} catch (Exception e) {
e.printStackTrace();
txMgr.rollback();
}
Will it cause a problem if I remove this transaction? To me it does
not seem to provide any value when the Process is being supplied by
Tuscany. I can't see any requirement for it in the ODE documentation.
Yours, Mike.
Rebuiling from scratch gives me the error below. Anybody else seeing
this? Could it be related to the transaction problem discussed here?
Running helloworld.BPELHelloWorldTestCase
org.apache.tuscany.sca.implementation.bpel.ode.ODEDeploymentException:
DEPLOY: Unexpected exception: Error reloading compiled process
{http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1;
the file appears to be corrupted.
at
org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.deploy(EmbeddedODEServer.java:285)
at
org.apache.tuscany.sca.implementation.bpel.provider.BPELImplementationProvider.start(BPELImplementationProvider.java:100)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:631)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:245)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
helloworld.BPELHelloWorldTestCase.setUp(BPELHelloWorldTestCase.java:42)
at junit.framework.TestCase.runBare(TestCase.java:125)
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
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
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:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
Caused by: org.apache.ode.bpel.iapi.BpelEngineException: Error
reloading compiled process
[jira] Updated: (TUSCANY-2011) include apache headers in xmls and xsds without causing test case failures
[ https://issues.apache.org/jira/browse/TUSCANY-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-2011: - Fix Version/s: (was: Java-SDO-Next) Java-SDO-1.1 include apache headers in xmls and xsds without causing test case failures -- Key: TUSCANY-2011 URL: https://issues.apache.org/jira/browse/TUSCANY-2011 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation, Java SDO Tools Affects Versions: Java-SDO-Next Reporter: Amita Vadhavkar Priority: Minor Fix For: Java-SDO-1.1 there are total 7 files in sdo-impl and 3 files in tools-test which can contain Apache headers without any test case failures, so do so for a successful RAT report -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2011) include apache headers in xmls and xsds without causing test case failures
[ https://issues.apache.org/jira/browse/TUSCANY-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar resolved TUSCANY-2011. -- Resolution: Fixed completed at revision 616270 include apache headers in xmls and xsds without causing test case failures -- Key: TUSCANY-2011 URL: https://issues.apache.org/jira/browse/TUSCANY-2011 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation, Java SDO Tools Affects Versions: Java-SDO-Next Reporter: Amita Vadhavkar Priority: Minor Fix For: Java-SDO-Next there are total 7 files in sdo-impl and 3 files in tools-test which can contain Apache headers without any test case failures, so do so for a successful RAT report -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2011) include apache headers in xmls and xsds without causing test case failures
include apache headers in xmls and xsds without causing test case failures -- Key: TUSCANY-2011 URL: https://issues.apache.org/jira/browse/TUSCANY-2011 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation, Java SDO Tools Affects Versions: Java-SDO-Next Reporter: Amita Vadhavkar Priority: Minor Fix For: Java-SDO-Next there are total 7 files in sdo-impl and 3 files in tools-test which can contain Apache headers without any test case failures, so do so for a successful RAT report -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test case failures
With Kevin's great help, we found the culprit. It seems that the SAX2DOM class from Xalan 2.7.0 cannot run with XercesImpl 2.8.0 with the following exception: java.lang.IncompatibleClassChangeError at org.apache.xalan.xsltc.trax.SAX2DOM.startElement(SAX2DOM.java:140) We tried to downgrade XercesImpl to 2.6.0 and it works! Kevin, do you want to commit the fix for now? I'm thinking of removing the Xalan dependency completely by copying the SAX2DOM utility into our code base. Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, July 27, 2006 9:39 AM Subject: Re: Test case failures Raymond was helping me with this yesterday. He noticed that if you run the build from the respective subdirectory, the test succeeds. It seems to only fail when the build is run from /java. ant elder wrote: I see the same failure with a fresh checkout of the code using the Sun Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Should I just commit a change to comment out the test for now? ...ant On 7/26/06, Kevin Williams [EMAIL PROTECTED] wrote: Yeah. I've tried those things and also just threw everything out and tried to build from a fresh svn co. Same problem. My verbose version info: javajava -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-2006050 4 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a --Kevin Brent Daniel wrote: Kevin, For what it's worth, I'm using a somewhat older version of the IBM JDK than Raymond, and I'm also not seeing an error here when I do a full build on a fresh checkout. If indeed your build did succeed once, then it doesn't sound like a dependency issue. Maybe you're running into some sort of network hiccup in subsequent builds? Have you tried running offline? (mvn -o) Do you still see the failure if you do a full clean and rebuild? FYI, my java -version: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20051104) Brent On 7/25/06, Kevin Williams [EMAIL PROTECTED] wrote: Hi Raymond, I get the same error with your patched POM. I don't think my version is a beta release and I am also unsure of DocumentBuilderFactory assumption. --Kevin Raymond Feng wrote: Hi, Kevin. Is the Technology Edition a beta release? Can we assume the JDK 5.0 always come with a DocumentBuilderFactory impl (I have never checked the JSE 5.0 spec)? I have the following IBM JDK and it runs fine. java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 10:57 PM Subject: Re: Test case failures Hi Raymond, I am using: IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 I tried your patch but the result is a new failure: == Downloading: http://repo1.maven.org/maven2/xerces/xerces/2.8.0/xerces-2.8.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.or /maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xerces:xerces:jar:2.8.0 === There is no 2.8.0 direcrory under xerces/xerces. I notice there is under xerces/xercesImpl --Kevin Raymond Feng wrote: Hi, Kevin. Which JDK do you use? It seems that it doesn't come with a DOM implementation. Can you try to apply the attched patch to databinding-framework/pom.xml? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 8:39 PM Subject: Test case failures After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found
Re: Test case failures
I see the same failure with a fresh checkout of the code using the Sun Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Should I just commit a change to comment out the test for now? ...ant On 7/26/06, Kevin Williams [EMAIL PROTECTED] wrote: Yeah. I've tried those things and also just threw everything out and tried to build from a fresh svn co. Same problem. My verbose version info: javajava -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-2006050 4 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a --Kevin Brent Daniel wrote: Kevin, For what it's worth, I'm using a somewhat older version of the IBM JDK than Raymond, and I'm also not seeing an error here when I do a full build on a fresh checkout. If indeed your build did succeed once, then it doesn't sound like a dependency issue. Maybe you're running into some sort of network hiccup in subsequent builds? Have you tried running offline? (mvn -o) Do you still see the failure if you do a full clean and rebuild? FYI, my java -version: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20051104) Brent On 7/25/06, Kevin Williams [EMAIL PROTECTED] wrote: Hi Raymond, I get the same error with your patched POM. I don't think my version is a beta release and I am also unsure of DocumentBuilderFactory assumption. --Kevin Raymond Feng wrote: Hi, Kevin. Is the Technology Edition a beta release? Can we assume the JDK 5.0 always come with a DocumentBuilderFactory impl (I have never checked the JSE 5.0 spec)? I have the following IBM JDK and it runs fine. java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 10:57 PM Subject: Re: Test case failures Hi Raymond, I am using: IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 I tried your patch but the result is a new failure: == Downloading: http://repo1.maven.org/maven2/xerces/xerces/2.8.0/xerces-2.8.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.or /maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xerces:xerces:jar:2.8.0 === There is no 2.8.0 direcrory under xerces/xerces. I notice there is under xerces/xercesImpl --Kevin Raymond Feng wrote: Hi, Kevin. Which JDK do you use? It seems that it doesn't come with a DOM implementation. Can you try to apply the attched patch to databinding-framework/pom.xml? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 8:39 PM Subject: Test case failures After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.apache.xalan.xsltc.trax.SAX2DOM.init(SAX2DOM.java :57) at org.apache.tuscany.databinding.xml.SAX2DOMPipe.init(SAX2DOMPipe.jav a:35) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.setUp(Mediat orImplTestCase.java:61) at junit.framework.TestCase.runBare (TestCase.java:125) 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
Re: Test case failures
Raymond was helping me with this yesterday. He noticed that if you run the build from the respective subdirectory, the test succeeds. It seems to only fail when the build is run from /java. ant elder wrote: I see the same failure with a fresh checkout of the code using the Sun Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Should I just commit a change to comment out the test for now? ...ant On 7/26/06, Kevin Williams [EMAIL PROTECTED] wrote: Yeah. I've tried those things and also just threw everything out and tried to build from a fresh svn co. Same problem. My verbose version info: javajava -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-2006050 4 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a --Kevin Brent Daniel wrote: Kevin, For what it's worth, I'm using a somewhat older version of the IBM JDK than Raymond, and I'm also not seeing an error here when I do a full build on a fresh checkout. If indeed your build did succeed once, then it doesn't sound like a dependency issue. Maybe you're running into some sort of network hiccup in subsequent builds? Have you tried running offline? (mvn -o) Do you still see the failure if you do a full clean and rebuild? FYI, my java -version: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20051104) Brent On 7/25/06, Kevin Williams [EMAIL PROTECTED] wrote: Hi Raymond, I get the same error with your patched POM. I don't think my version is a beta release and I am also unsure of DocumentBuilderFactory assumption. --Kevin Raymond Feng wrote: Hi, Kevin. Is the Technology Edition a beta release? Can we assume the JDK 5.0 always come with a DocumentBuilderFactory impl (I have never checked the JSE 5.0 spec)? I have the following IBM JDK and it runs fine. java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 10:57 PM Subject: Re: Test case failures Hi Raymond, I am using: IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 I tried your patch but the result is a new failure: == Downloading: http://repo1.maven.org/maven2/xerces/xerces/2.8.0/xerces-2.8.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.or /maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xerces:xerces:jar:2.8.0 === There is no 2.8.0 direcrory under xerces/xerces. I notice there is under xerces/xercesImpl --Kevin Raymond Feng wrote: Hi, Kevin. Which JDK do you use? It seems that it doesn't come with a DOM implementation. Can you try to apply the attched patch to databinding-framework/pom.xml? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 8:39 PM Subject: Test case failures After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.apache.xalan.xsltc.trax.SAX2DOM.init(SAX2DOM.java :57) at org.apache.tuscany.databinding.xml.SAX2DOMPipe.init(SAX2DOMPipe.jav a:35) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.setUp(Mediat orImplTestCase.java:61) at junit.framework.TestCase.runBare (TestCase.java:125) 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
Re: Test case failures
Sorry, the artifactId should be xercesImpl. Can you try that? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 10:57 PM Subject: Re: Test case failures Hi Raymond, I am using: IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 I tried your patch but the result is a new failure: == Downloading: http://repo1.maven.org/maven2/xerces/xerces/2.8.0/xerces-2.8.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.or /maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xerces:xerces:jar:2.8.0 === There is no 2.8.0 direcrory under xerces/xerces. I notice there is under xerces/xercesImpl --Kevin Raymond Feng wrote: Hi, Kevin. Which JDK do you use? It seems that it doesn't come with a DOM implementation. Can you try to apply the attched patch to databinding-framework/pom.xml? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 8:39 PM Subject: Test case failures After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.apache.xalan.xsltc.trax.SAX2DOM.init(SAX2DOM.java:57) at org.apache.tuscany.databinding.xml.SAX2DOMPipe.init(SAX2DOMPipe.jav a:35) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.setUp(Mediat orImplTestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:125) 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:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBatt ery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.j ava:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at org.apache.maven.surefire.Surefire.run(Surefire.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785 ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Index: pom.xml === --- pom.xml(revision 425233) +++ pom.xml(working copy) @@ -47,6 +47,12 @@ scopecompile/scope /dependency dependency +groupIdxerces/groupId +artifactIdxerces/artifactId +version2.8.0/version +scopetest/scope +/dependency +dependency groupIdjunit/groupId artifactIdjunit/artifactId /dependency - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: Test case failures
Hi, Kevin. Is the Technology Edition a beta release? Can we assume the JDK 5.0 always come with a DocumentBuilderFactory impl (I have never checked the JSE 5.0 spec)? I have the following IBM JDK and it runs fine. java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 10:57 PM Subject: Re: Test case failures Hi Raymond, I am using: IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 I tried your patch but the result is a new failure: == Downloading: http://repo1.maven.org/maven2/xerces/xerces/2.8.0/xerces-2.8.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.or /maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xerces:xerces:jar:2.8.0 === There is no 2.8.0 direcrory under xerces/xerces. I notice there is under xerces/xercesImpl --Kevin Raymond Feng wrote: Hi, Kevin. Which JDK do you use? It seems that it doesn't come with a DOM implementation. Can you try to apply the attched patch to databinding-framework/pom.xml? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 8:39 PM Subject: Test case failures After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.apache.xalan.xsltc.trax.SAX2DOM.init(SAX2DOM.java:57) at org.apache.tuscany.databinding.xml.SAX2DOMPipe.init(SAX2DOMPipe.jav a:35) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.setUp(Mediat orImplTestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:125) 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:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBatt ery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.j ava:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at org.apache.maven.surefire.Surefire.run(Surefire.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785 ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Index: pom.xml === --- pom.xml(revision 425233) +++ pom.xml(working copy) @@ -47,6 +47,12 @@ scopecompile/scope /dependency dependency +groupIdxerces/groupId +artifactIdxerces/artifactId +version2.8.0/version +scopetest/scope +/dependency +dependency groupIdjunit/groupId artifactIdjunit/artifactId /dependency
Re: Test case failures
Hi Raymond, I get the same error with your patched POM. I don't think my version is a beta release and I am also unsure of DocumentBuilderFactory assumption. --Kevin Raymond Feng wrote: Hi, Kevin. Is the Technology Edition a beta release? Can we assume the JDK 5.0 always come with a DocumentBuilderFactory impl (I have never checked the JSE 5.0 spec)? I have the following IBM JDK and it runs fine. java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 10:57 PM Subject: Re: Test case failures Hi Raymond, I am using: IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 I tried your patch but the result is a new failure: == Downloading: http://repo1.maven.org/maven2/xerces/xerces/2.8.0/xerces-2.8.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.or /maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xerces:xerces:jar:2.8.0 === There is no 2.8.0 direcrory under xerces/xerces. I notice there is under xerces/xercesImpl --Kevin Raymond Feng wrote: Hi, Kevin. Which JDK do you use? It seems that it doesn't come with a DOM implementation. Can you try to apply the attched patch to databinding-framework/pom.xml? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 8:39 PM Subject: Test case failures After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.apache.xalan.xsltc.trax.SAX2DOM.init(SAX2DOM.java:57) at org.apache.tuscany.databinding.xml.SAX2DOMPipe.init(SAX2DOMPipe.jav a:35) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.setUp(Mediat orImplTestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:125) 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:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBatt ery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.j ava:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at org.apache.maven.surefire.Surefire.run(Surefire.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785 ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Index: pom.xml === --- pom.xml(revision 425233) +++ pom.xml(working copy) @@ -47,6 +47,12 @@ scopecompile/scope /dependency dependency +groupIdxerces/groupId +artifactIdxerces/artifactId
Re: Test case failures
Kevin, For what it's worth, I'm using a somewhat older version of the IBM JDK than Raymond, and I'm also not seeing an error here when I do a full build on a fresh checkout. If indeed your build did succeed once, then it doesn't sound like a dependency issue. Maybe you're running into some sort of network hiccup in subsequent builds? Have you tried running offline? (mvn -o) Do you still see the failure if you do a full clean and rebuild? FYI, my java -version: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20051104) Brent On 7/25/06, Kevin Williams [EMAIL PROTECTED] wrote: Hi Raymond, I get the same error with your patched POM. I don't think my version is a beta release and I am also unsure of DocumentBuilderFactory assumption. --Kevin Raymond Feng wrote: Hi, Kevin. Is the Technology Edition a beta release? Can we assume the JDK 5.0 always come with a DocumentBuilderFactory impl (I have never checked the JSE 5.0 spec)? I have the following IBM JDK and it runs fine. java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 10:57 PM Subject: Re: Test case failures Hi Raymond, I am using: IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 I tried your patch but the result is a new failure: == Downloading: http://repo1.maven.org/maven2/xerces/xerces/2.8.0/xerces-2.8.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.or /maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xerces:xerces:jar:2.8.0 === There is no 2.8.0 direcrory under xerces/xerces. I notice there is under xerces/xercesImpl --Kevin Raymond Feng wrote: Hi, Kevin. Which JDK do you use? It seems that it doesn't come with a DOM implementation. Can you try to apply the attched patch to databinding-framework/pom.xml? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 8:39 PM Subject: Test case failures After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.apache.xalan.xsltc.trax.SAX2DOM.init(SAX2DOM.java:57) at org.apache.tuscany.databinding.xml.SAX2DOMPipe.init(SAX2DOMPipe.jav a:35) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.setUp(Mediat orImplTestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:125) 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:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBatt ery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.j ava:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at org.apache.maven.surefire.Surefire.run(Surefire.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64
Re: Test case failures
Hmm, I just checked the package of xercesImpl-2.8.0.jar. It does have a file META-INF/services/javax.xml.parsers.DocumentBuilderFactory which lists org.apache.xerces.jaxp.DocumentBuilderFactoryImpl. By the javadoc @ http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/parsers/DocumentBuilderFactory.html#newInstance(), the call should be successful. Can you try SUN JDK as well? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 25, 2006 1:17 PM Subject: Re: Test case failures Hi Raymond, I get the same error with your patched POM. I don't think my version is a beta release and I am also unsure of DocumentBuilderFactory assumption. --Kevin Raymond Feng wrote: Hi, Kevin. Is the Technology Edition a beta release? Can we assume the JDK 5.0 always come with a DocumentBuilderFactory impl (I have never checked the JSE 5.0 spec)? I have the following IBM JDK and it runs fine. java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 10:57 PM Subject: Re: Test case failures Hi Raymond, I am using: IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 I tried your patch but the result is a new failure: == Downloading: http://repo1.maven.org/maven2/xerces/xerces/2.8.0/xerces-2.8.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.or /maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xerces:xerces:jar:2.8.0 === There is no 2.8.0 direcrory under xerces/xerces. I notice there is under xerces/xercesImpl --Kevin Raymond Feng wrote: Hi, Kevin. Which JDK do you use? It seems that it doesn't come with a DOM implementation. Can you try to apply the attched patch to databinding-framework/pom.xml? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 8:39 PM Subject: Test case failures After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.apache.xalan.xsltc.trax.SAX2DOM.init(SAX2DOM.java:57) at org.apache.tuscany.databinding.xml.SAX2DOMPipe.init(SAX2DOMPipe.jav a:35) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.setUp(Mediat orImplTestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:125) 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:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBatt ery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.j ava:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at org.apache.maven.surefire.Surefire.run(Surefire.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615
Re: Test case failures
Yeah. I've tried those things and also just threw everything out and tried to build from a fresh svn co. Same problem. My verbose version info: javajava -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-2006050 4 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a --Kevin Brent Daniel wrote: Kevin, For what it's worth, I'm using a somewhat older version of the IBM JDK than Raymond, and I'm also not seeing an error here when I do a full build on a fresh checkout. If indeed your build did succeed once, then it doesn't sound like a dependency issue. Maybe you're running into some sort of network hiccup in subsequent builds? Have you tried running offline? (mvn -o) Do you still see the failure if you do a full clean and rebuild? FYI, my java -version: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20051104) Brent On 7/25/06, Kevin Williams [EMAIL PROTECTED] wrote: Hi Raymond, I get the same error with your patched POM. I don't think my version is a beta release and I am also unsure of DocumentBuilderFactory assumption. --Kevin Raymond Feng wrote: Hi, Kevin. Is the Technology Edition a beta release? Can we assume the JDK 5.0 always come with a DocumentBuilderFactory impl (I have never checked the JSE 5.0 spec)? I have the following IBM JDK and it runs fine. java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 10:57 PM Subject: Re: Test case failures Hi Raymond, I am using: IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 I tried your patch but the result is a new failure: == Downloading: http://repo1.maven.org/maven2/xerces/xerces/2.8.0/xerces-2.8.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.or /maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xerces:xerces:jar:2.8.0 === There is no 2.8.0 direcrory under xerces/xerces. I notice there is under xerces/xercesImpl --Kevin Raymond Feng wrote: Hi, Kevin. Which JDK do you use? It seems that it doesn't come with a DOM implementation. Can you try to apply the attched patch to databinding-framework/pom.xml? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 8:39 PM Subject: Test case failures After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.apache.xalan.xsltc.trax.SAX2DOM.init(SAX2DOM.java:57) at org.apache.tuscany.databinding.xml.SAX2DOMPipe.init(SAX2DOMPipe.jav a:35) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.setUp(Mediat orImplTestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:125) 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:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBatt ery.java:242
Java core test case failures?
Hello, Seeing the below error on java main trunk. Building on XP Sun java full version 1.5.0_07-b03 rev 425055 on java Maven version: 2.0.4 [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Tuscany Build Tools [INFO] SDO API [INFO] SCA API [INFO] Commonj [INFO] OSOA Specification API jars [INFO] Tuscany SDO Implementation Project [INFO] Tuscany SDO Implementation [INFO] Tuscany SDO Tools [INFO] Tuscany SDO Maven Plugin [INFO] Tuscany DAS [INFO] Tuscany DAS for Relational Databases [INFO] Tuscany DAS Samples [INFO] Tuscany DAS Company Sample [INFO] Tuscany SCA Implementation Project [INFO] Apache Tuscany SCA SPI [INFO] Apache Tuscany SCA Core [INFO] Apache Tuscany Test Framework [INFO] Tuscany SCA Containers [INFO] Apache Tuscany Groovy Container [INFO] Apache Tuscany Spring Framework Container [INFO] Tuscany SCA Data Bindings [INFO] Apache Tuscany Data Binding Framework [INFO] Apache Tuscany Data Binding for Axiom [INFO] Apache Tuscany Data Binding for Castor [INFO] Apache Tuscany Data Binding for JAXB [INFO] Apache Tuscany Data Binding for SDO [INFO] Apache Tuscany Data Binding for XmlBeans [INFO] Data Binding Integration Test [INFO] Tuscany SCA Bindings [INFO] Project to install the Sun jars [INFO] Apache Tuscany Binding for Celtix [INFO] Apache Tuscany RMI Binding [INFO] Tuscany SCA Services [INFO] Apache Tuscany Jetty HTTP Service [INFO] Apache Tuscany SCA Application Launcher [INFO] Tuscany SCA Samples [INFO] Tuscany Eagerinit Sample [INFO] Tuscany Local Wiring Sample [INFO] Tuscany Local CDI Wiring Sample [INFO] Tuscany Calculator Sample [INFO] Tuscany Supply Chain Sample [INFO] Tuscany Standalone Distribution [INFO] Tuscany Project [INFO] [INFO] Building Tuscany Build Tools [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] No sources to compile [INFO] [surefire:test] [INFO] No tests to run. [INFO] [jar:jar] [INFO] Building jar: E:\dev\tuscany\java\buildtools\target\buildtools-1.0-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing E:\dev\tuscany\java\buildtools\target\buildtools-1.0-SNAPSHOT.jar to C:\Documents and Settings\rineholt\.m2\repository\org\apache\tuscany\buildtools\1.0-SNAPSHOT\buildtools-1.0-SNAPSHOT.jar [INFO] [INFO] Building SDO API [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Surefire report directory: E:\dev\tuscany\java\spec\sdo\target\surefire-reports --- T E S T S --- Running commonj.sdo.impl.HelperProviderTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec Results : Tests run: 5, Failures: 0, Errors: 0, Skipped: 0 [INFO] [jar:jar] [INFO] Building jar: E:\dev\tuscany\java\spec\sdo\target\sdo-api-1.0-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing E:\dev\tuscany\java\spec\sdo\target\sdo-api-1.0-SNAPSHOT.jar to C:\Documents and Settings\rineholt\.m2\repository\commonj\sdo-api\1.0-SNAPSHOT\sdo-api-1.0-SNAPSHOT.jar [INFO] [INFO] Building SCA API [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Surefire report directory: E:\dev\tuscany\java\spec\sca\target\surefire-reports --- T E S T S --- Running org.osoa.sca.annotations.CallbackTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec Results : Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
Re: Java core test case failures?
On Jul 24, 2006, at 7:30 AM, Rick wrote: testSchedule (org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManagerTestCase) Time elapsed: 0 sec ERROR! java.lang.AssertionError: Expectation failure on verify: run(): expected: 1, actual: 0 at org.easymock.internal.MocksControl.verify(MocksControl.java:71) at org.easymock.EasyMock.verify(EasyMock.java:1306) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWor kManagerTestCase.testSchedule(ThreadPoolWorkManagerTestCase.java:25) This looks like a basic race condition in the testcase. Perhaps we should add a constructor to ThreadPoolWorkManager that allows the Executor to be mocked. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java core test case failures?
Yea it is. I just checked in a fix. Please let me know if it works on your machine, Rick. Jim On Jul 24, 2006, at 7:48 AM, Jeremy Boynes wrote: On Jul 24, 2006, at 7:30 AM, Rick wrote: testSchedule (org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolW orkManagerTestCase) Time elapsed: 0 sec ERROR! java.lang.AssertionError: Expectation failure on verify: run(): expected: 1, actual: 0 at org.easymock.internal.MocksControl.verify(MocksControl.java:71) at org.easymock.EasyMock.verify(EasyMock.java:1306) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManagerTestCase.testSchedule(ThreadPoolWorkManagerTestCase.java:25) This looks like a basic race condition in the testcase. Perhaps we should add a constructor to ThreadPoolWorkManager that allows the Executor to be mocked. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java core test case failures?
I was seeing a similar error as Rick, I updated and picked up the fix and now I see the following error, after which the build hangs (suspecting a deadlock now): [surefire] Running org.apache.tuscany.core.services.work.jsr237.Jsr237WorkSchedu lerTestCase [surefire] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.01 sec [surefire] Exception in thread pool-8-thread-1 java.lang.AssertionError: Unexpected method call workStarted(org.apache.tuscany.core.services.work.jsr23 [EMAIL PROTECTED]): workAccepted(isA(commonj.work.WorkEvent)): expected: 1, actual: 0 at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHand ler.java:29) at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter. java:45) at $Proxy50.workStarted(Unknown Source) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager.workStarted(ThreadPoolWorkManager.java:140) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager.access$100(ThreadPoolWorkManager.java:45) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:201) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec utor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:675) at java.lang.Thread.run(Thread.java:595) - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 11:00 AM Subject: Re: Java core test case failures? Yea it is. I just checked in a fix. Please let me know if it works on your machine, Rick. Jim On Jul 24, 2006, at 7:48 AM, Jeremy Boynes wrote: On Jul 24, 2006, at 7:30 AM, Rick wrote: testSchedule (org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolW orkManagerTestCase) Time elapsed: 0 sec ERROR! java.lang.AssertionError: Expectation failure on verify: run(): expected: 1, actual: 0 at org.easymock.internal.MocksControl.verify(MocksControl.java:71) at org.easymock.EasyMock.verify(EasyMock.java:1306) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManagerTestCase.testSchedule(ThreadPoolWorkManagerTestCase.java:25) This looks like a basic race condition in the testcase. Perhaps we should add a constructor to ThreadPoolWorkManager that allows the Executor to be mocked. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java core test case failures?
O.K. the easiest thing I think to do is what Jeremy mentioned and stub out the Executor since this is going to cause issues on different machines. I've commented out the test cases for now and I'll go back in later and stub out the Executor. Jim On Jul 24, 2006, at 8:15 AM, Ignacio Silva-Lepe wrote: I was seeing a similar error as Rick, I updated and picked up the fix and now I see the following error, after which the build hangs (suspecting a deadlock now): [surefire] Running org.apache.tuscany.core.services.work.jsr237.Jsr237WorkSchedu lerTestCase [surefire] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.01 sec [surefire] Exception in thread pool-8-thread-1 java.lang.AssertionError: Unexpected method call workStarted (org.apache.tuscany.core.services.work.jsr23 [EMAIL PROTECTED]): workAccepted(isA(commonj.work.WorkEvent)): expected: 1, actual: 0 at org.easymock.internal.MockInvocationHandler.invoke (MockInvocationHand ler.java:29) at org.easymock.internal.ObjectMethodsFilter.invoke (ObjectMethodsFilter. java:45) at $Proxy50.workStarted(Unknown Source) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager.workStarted(ThreadPoolWorkManager.java:140) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager.access$100(ThreadPoolWorkManager.java:45) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:201) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask (ThreadPoolExec utor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor .java:675) at java.lang.Thread.run(Thread.java:595) - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 11:00 AM Subject: Re: Java core test case failures? Yea it is. I just checked in a fix. Please let me know if it works on your machine, Rick. Jim On Jul 24, 2006, at 7:48 AM, Jeremy Boynes wrote: On Jul 24, 2006, at 7:30 AM, Rick wrote: testSchedule (org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoo lW orkManagerTestCase) Time elapsed: 0 sec ERROR! java.lang.AssertionError: Expectation failure on verify: run(): expected: 1, actual: 0 at org.easymock.internal.MocksControl.verify (MocksControl.java:71) at org.easymock.EasyMock.verify(EasyMock.java:1306) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPool Wo rkManagerTestCase.testSchedule (ThreadPoolWorkManagerTestCase.java:25) This looks like a basic race condition in the testcase. Perhaps we should add a constructor to ThreadPoolWorkManager that allows the Executor to be mocked. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java core test case failures?
rkManager.workStarted(ThreadPoolWorkManager.java:140) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager.access$100(ThreadPoolWorkManager.java:45) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:201) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec utor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:675) at java.lang.Thread.run(Thread.java:595) - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 11:00 AM Subject: Re: Java core test case failures? Yea it is. I just checked in a fix. Please let me know if it works on your machine, Rick. Jim On Jul 24, 2006, at 7:48 AM, Jeremy Boynes wrote: On Jul 24, 2006, at 7:30 AM, Rick wrote: testSchedule (org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolW orkManagerTestCase) Time elapsed: 0 sec ERROR! java.lang.AssertionError: Expectation failure on verify: run(): expected: 1, actual: 0 at org.easymock.internal.MocksControl.verify(MocksControl.java:71) at org.easymock.EasyMock.verify(EasyMock.java:1306) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManagerTestCase.testSchedule(ThreadPoolWorkManagerTestCase.java:25) This looks like a basic race condition in the testcase. Perhaps we should add a constructor to ThreadPoolWorkManager that allows the Executor to be mocked. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java core test case failures?
Jim,
I think it is an implementation issue in the ThreadPoolWorkManager
itself. With the current implementation, it is likely for workStarted to
be called before the workAccepted event.
01public WorkItem schedule(Work work, WorkListener workListener)
throws WorkRejectedException {
02
03DefaultWorkItem workItem = new DefaultWorkItem(new
UID().toString(), work);
04if (scheduleWork(work, workItem)) {
05 if (workListener != null) {
06 workItems.put(workItem, workListener);
07 }
08 workAccepted(workItem, work);
09 return workItem;
10} else {
11workItem.setStatus(WorkEvent.WORK_REJECTED);
12if (workListener != null) {
13workListener.workRejected(new
DefaultWorkEvent(workItem));
14}
15throw new WorkRejectedException(Unable to schedule
work);
16 }
17}
18
19private boolean scheduleWork(final Work work, final
DefaultWorkItem workItem) {
20try {
21 executor.execute(new DecoratingWork(workItem, work));
22 return true;
23} catch (RejectedExecutionException ex) {
24return false;
25}
26}
In the snippet above the executor may start executing the runnable
before line 8 is executed. A fix could be to call workAccepted in the
decorated work just before workStarted in the same thread.
I am checking out the latest source. I will have a closer look and
submit a patch by tonight or tomorrow morning.
Ta
Meeraj
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 24 July 2006 16:21
To: tuscany-dev@ws.apache.org
Subject: Re: Java core test case failures?
O.K. the easiest thing I think to do is what Jeremy mentioned and stub
out the Executor since this is going to cause issues on different
machines. I've commented out the test cases for now and I'll go back in
later and stub out the Executor.
Jim
On Jul 24, 2006, at 8:15 AM, Ignacio Silva-Lepe wrote:
I was seeing a similar error as Rick, I updated and picked up the fix
and now I see the following error, after which the build hangs
(suspecting a deadlock now):
[surefire] Running
org.apache.tuscany.core.services.work.jsr237.Jsr237WorkSchedu
lerTestCase
[surefire] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.01
sec [surefire]
Exception in thread pool-8-thread-1 java.lang.AssertionError:
Unexpected method call workStarted
(org.apache.tuscany.core.services.work.jsr23
[EMAIL PROTECTED]):
workAccepted(isA(commonj.work.WorkEvent)): expected: 1, actual: 0
at org.easymock.internal.MockInvocationHandler.invoke
(MockInvocationHand
ler.java:29)
at org.easymock.internal.ObjectMethodsFilter.invoke
(ObjectMethodsFilter.
java:45)
at $Proxy50.workStarted(Unknown Source)
at
org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo
rkManager.workStarted(ThreadPoolWorkManager.java:140)
at
org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo
rkManager.access$100(ThreadPoolWorkManager.java:45)
at
org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo
rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:201)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask
(ThreadPoolExec
utor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor
.java:675)
at java.lang.Thread.run(Thread.java:595)
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, July 24, 2006 11:00 AM
Subject: Re: Java core test case failures?
Yea it is. I just checked in a fix. Please let me know if it works on
your machine, Rick.
Jim
On Jul 24, 2006, at 7:48 AM, Jeremy Boynes wrote:
On Jul 24, 2006, at 7:30 AM, Rick wrote:
testSchedule
(org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoo
lW orkManagerTestCase) Time elapsed: 0 sec ERROR!
java.lang.AssertionError:
Expectation failure on verify:
run(): expected: 1, actual: 0
at org.easymock.internal.MocksControl.verify
(MocksControl.java:71)
at org.easymock.EasyMock.verify(EasyMock.java:1306)
at
org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPool
Wo rkManagerTestCase.testSchedule
(ThreadPoolWorkManagerTestCase.java:25)
This looks like a basic race condition in the testcase. Perhaps we
should add a constructor to ThreadPoolWorkManager that allows the
Executor to be mocked.
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail
Re: Java core test case failures?
(commonj.work.WorkEvent)): expected: 1, actual: 0 at org.easymock.internal.MockInvocationHandler.invoke (MockInvocationHand ler.java:29) at org.easymock.internal.ObjectMethodsFilter.invoke (ObjectMethodsFilter. java:45) at $Proxy50.workStarted(Unknown Source) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolW o rkManager.workStarted(ThreadPoolWorkManager.java:140) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolW o rkManager.access$100(ThreadPoolWorkManager.java:45) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolW o rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:201) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask (ThreadPoolExec utor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor .java:675) at java.lang.Thread.run(Thread.java:595) - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 11:00 AM Subject: Re: Java core test case failures? Yea it is. I just checked in a fix. Please let me know if it works on your machine, Rick. Jim On Jul 24, 2006, at 7:48 AM, Jeremy Boynes wrote: On Jul 24, 2006, at 7:30 AM, Rick wrote: testSchedule (org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadP oolW orkManagerTestCase) Time elapsed: 0 sec ERROR! java.lang.AssertionError: Expectation failure on verify: run(): expected: 1, actual: 0 at org.easymock.internal.MocksControl.verify (MocksControl.java:71) at org.easymock.EasyMock.verify(EasyMock.java:1306) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPo olWo rkManagerTestCase.testSchedule (ThreadPoolWorkManagerTestCase.java:25) This looks like a basic race condition in the testcase. Perhaps we should add a constructor to ThreadPoolWorkManager that allows the Executor to be mocked. -- Jeremy -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java core test case failures?
O.K. thx Meeraj. I commented out the test cases so whenever you get
a chance, it would be much appreciated.
Jim
On Jul 24, 2006, at 8:47 AM, Meeraj Kunnumpurath wrote:
Jim,
I think it is an implementation issue in the ThreadPoolWorkManager
itself. With the current implementation, it is likely for
workStarted to
be called before the workAccepted event.
01public WorkItem schedule(Work work, WorkListener workListener)
throws WorkRejectedException {
02
03DefaultWorkItem workItem = new DefaultWorkItem(new
UID().toString(), work);
04if (scheduleWork(work, workItem)) {
05 if (workListener != null) {
06 workItems.put(workItem, workListener);
07 }
08 workAccepted(workItem, work);
09 return workItem;
10} else {
11workItem.setStatus(WorkEvent.WORK_REJECTED);
12if (workListener != null) {
13workListener.workRejected(new
DefaultWorkEvent(workItem));
14}
15throw new WorkRejectedException(Unable to schedule
work);
16 }
17}
18
19private boolean scheduleWork(final Work work, final
DefaultWorkItem workItem) {
20try {
21 executor.execute(new DecoratingWork(workItem, work));
22 return true;
23} catch (RejectedExecutionException ex) {
24return false;
25}
26}
In the snippet above the executor may start executing the runnable
before line 8 is executed. A fix could be to call workAccepted in the
decorated work just before workStarted in the same thread.
I am checking out the latest source. I will have a closer look and
submit a patch by tonight or tomorrow morning.
Ta
Meeraj
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 24 July 2006 16:21
To: tuscany-dev@ws.apache.org
Subject: Re: Java core test case failures?
O.K. the easiest thing I think to do is what Jeremy mentioned and stub
out the Executor since this is going to cause issues on different
machines. I've commented out the test cases for now and I'll go
back in
later and stub out the Executor.
Jim
On Jul 24, 2006, at 8:15 AM, Ignacio Silva-Lepe wrote:
I was seeing a similar error as Rick, I updated and picked up the fix
and now I see the following error, after which the build hangs
(suspecting a deadlock now):
[surefire] Running
org.apache.tuscany.core.services.work.jsr237.Jsr237WorkSchedu
lerTestCase
[surefire] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.01
sec [surefire]
Exception in thread pool-8-thread-1 java.lang.AssertionError:
Unexpected method call workStarted
(org.apache.tuscany.core.services.work.jsr23
[EMAIL PROTECTED]):
workAccepted(isA(commonj.work.WorkEvent)): expected: 1, actual: 0
at org.easymock.internal.MockInvocationHandler.invoke
(MockInvocationHand
ler.java:29)
at org.easymock.internal.ObjectMethodsFilter.invoke
(ObjectMethodsFilter.
java:45)
at $Proxy50.workStarted(Unknown Source)
at
org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo
rkManager.workStarted(ThreadPoolWorkManager.java:140)
at
org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo
rkManager.access$100(ThreadPoolWorkManager.java:45)
at
org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo
rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:201)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask
(ThreadPoolExec
utor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor
.java:675)
at java.lang.Thread.run(Thread.java:595)
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, July 24, 2006 11:00 AM
Subject: Re: Java core test case failures?
Yea it is. I just checked in a fix. Please let me know if it
works on
your machine, Rick.
Jim
On Jul 24, 2006, at 7:48 AM, Jeremy Boynes wrote:
On Jul 24, 2006, at 7:30 AM, Rick wrote:
testSchedule
(org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPo
o
lW orkManagerTestCase) Time elapsed: 0 sec ERROR!
java.lang.AssertionError:
Expectation failure on verify:
run(): expected: 1, actual: 0
at org.easymock.internal.MocksControl.verify
(MocksControl.java:71)
at org.easymock.EasyMock.verify(EasyMock.java:1306)
at
org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoo
l
Wo rkManagerTestCase.testSchedule
(ThreadPoolWorkManagerTestCase.java:25)
This looks like a basic race condition in the testcase. Perhaps we
should add a constructor to ThreadPoolWorkManager that allows the
Executor to be mocked.
--
Jeremy
---
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
Re: Java core test case failures?
(org.apache.tuscany.core.services.work.jsr23 [EMAIL PROTECTED]): workAccepted(isA(commonj.work.WorkEvent)): expected: 1, actual: 0 at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHand ler.java:29) at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter. java:45) at $Proxy50.workStarted(Unknown Source) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager.workStarted(ThreadPoolWorkManager.java:140) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager.access$100(ThreadPoolWorkManager.java:45) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:201) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec utor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:675) at java.lang.Thread.run(Thread.java:595) - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 11:00 AM Subject: Re: Java core test case failures? Yea it is. I just checked in a fix. Please let me know if it works on your machine, Rick. Jim On Jul 24, 2006, at 7:48 AM, Jeremy Boynes wrote: On Jul 24, 2006, at 7:30 AM, Rick wrote: testSchedule (org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolW orkManagerTestCase) Time elapsed: 0 sec ERROR! java.lang.AssertionError: Expectation failure on verify: run(): expected: 1, actual: 0 at org.easymock.internal.MocksControl.verify(MocksControl.java:71) at org.easymock.EasyMock.verify(EasyMock.java:1306) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManagerTestCase.testSchedule(ThreadPoolWorkManagerTestCase.java:25) This looks like a basic race condition in the testcase. Perhaps we should add a constructor to ThreadPoolWorkManager that allows the Executor to be mocked. --Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Test case failures
After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.apache.xalan.xsltc.trax.SAX2DOM.init(SAX2DOM.java:57) at org.apache.tuscany.databinding.xml.SAX2DOMPipe.init(SAX2DOMPipe.jav a:35) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.setUp(Mediat orImplTestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:125) 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:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBatt ery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.j ava:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at org.apache.maven.surefire.Surefire.run(Surefire.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785 ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test case failures
Hi, Kevin. Which JDK do you use? It seems that it doesn't come with a DOM implementation. Can you try to apply the attched patch to databinding-framework/pom.xml? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 8:39 PM Subject: Test case failures After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.apache.xalan.xsltc.trax.SAX2DOM.init(SAX2DOM.java:57) at org.apache.tuscany.databinding.xml.SAX2DOMPipe.init(SAX2DOMPipe.jav a:35) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.setUp(Mediat orImplTestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:125) 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:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBatt ery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.j ava:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at org.apache.maven.surefire.Surefire.run(Surefire.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785 ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Index: pom.xml === --- pom.xml (revision 425233) +++ pom.xml (working copy) @@ -47,6 +47,12 @@ scopecompile/scope /dependency dependency +groupIdxerces/groupId +artifactIdxerces/artifactId +version2.8.0/version +scopetest/scope +/dependency +dependency groupIdjunit/groupId artifactIdjunit/artifactId /dependency - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test case failures
Hi Raymond, I am using: IBM 32-bit SDK and Runtime Environment for Windows, Java 2 Technology Edition, Version 5.0 I tried your patch but the result is a new failure: == Downloading: http://repo1.maven.org/maven2/xerces/xerces/2.8.0/xerces-2.8.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.or /maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) xerces:xerces:jar:2.8.0 === There is no 2.8.0 direcrory under xerces/xerces. I notice there is under xerces/xercesImpl --Kevin Raymond Feng wrote: Hi, Kevin. Which JDK do you use? It seems that it doesn't come with a DOM implementation. Can you try to apply the attched patch to databinding-framework/pom.xml? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, July 24, 2006 8:39 PM Subject: Test case failures After having trouble getting svn update to succeed I reloaded the entire java tree. The first build attempt succeeded, I am almost certain :-), but subsequent attempts fail with this error: [surefire] Running org.apache.tuscany.databinding.impl.MediatorImplTestCase [surefire] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.041 sec [surefire] [surefire] testTransform1(org.apache.tuscany.databinding.impl.MediatorImplTestCa se) Time elapsed: 0.031 sec ERROR! javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.Docu mentBuilderFactory cannot be found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.apache.xalan.xsltc.trax.SAX2DOM.init(SAX2DOM.java:57) at org.apache.tuscany.databinding.xml.SAX2DOMPipe.init(SAX2DOMPipe.jav a:35) at org.apache.tuscany.databinding.impl.MediatorImplTestCase.setUp(Mediat orImplTestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:125) 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:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBatt ery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.j ava:216) at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at org.apache.maven.surefire.Surefire.run(Surefire.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785 ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Index: pom.xml === --- pom.xml(revision 425233) +++ pom.xml(working copy) @@ -47,6 +47,12 @@ scopecompile/scope /dependency dependency +groupIdxerces/groupId +artifactIdxerces/artifactId +version2.8.0/version +scopetest/scope +/dependency +dependency groupIdjunit/groupId artifactIdjunit/artifactId /dependency - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Java assertion related test case failures
Hi,
I ran into some test case failures with the trunk code in both Eclipse and
Maven (reported by my continumm build) related to the usage of java
assertions.
For example, in test case
org.apache.tuscany.spi.extension.ReferenceTestCase, we have the following
test:
public void testPrepare() throws Exception {
TestReference ref = new TestReference(null, null, null);
try {
ref.prepare(); //[rfeng] We assume the assert will catch null before
it moves on to NPE
fail();
} catch (AssertionError e) {
//expected // [rfeng] NPE is thrown if assertion is not enabled
}
}
By default, assertions are disabled by JVM unless you explicitly turned it
on using -ea option on the VM (In Eclipse, you need to set the VM
arguments either at the JRE or test case.profile level. For Maven, you may
need to set MAVEN_OPTS to include -ea). As a result, the test case fails
because it throws NullPointerException instead of AssertionError.
Should we improve these test cases to be more robust?
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java assertion related test case failures
For those who are interested, there's a nice article about java assertions @
http://www.javaworld.com/javaworld/jw-11-2001/jw-1109-assert.html. And the
following is quoted from it:
Expressions within an assert statement should not produce side effects,
since doing so exposes program execution to potentially different behavior
with and without assertions enabled. You should use assertions to produce
more reliable programs, not less reliable ones.
Finally, caution must guide the development of the expressions used in
assert statements. In addition to not producing side effects, assertions
should not alter normal program execution.
I think I buy what the author says.
Thanks,
Raymond
- Original Message -
From: Yang ZHONG [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, July 20, 2006 3:11 PM
Subject: Re: Java assertion related test case failures
I hope our code are not designated to run in some specifically configured
JVM.
Since JVMs may turn assertion on or off, I'm not sure AssertionError
should
be an expected behavior in general.
Dedicated exceptions and errors are much better protocol, e.g.
IndexOutOfBoundsException and OutOfMemoryError give much more
specific/useful info than plain AssertionError, not to mention assertion
isn't really born for error reporting.
On 7/20/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
Assertions should be enabled when running our test cases.
I have added an AssertionTestCase to the spi module that will cause
the build to fail if assertions are not enabled.
--
Jeremy
On Jul 20, 2006, at 9:36 AM, Raymond Feng wrote:
Hi,
I ran into some test case failures with the trunk code in both
Eclipse and Maven (reported by my continumm build) related to the
usage of java assertions.
For example, in test case
org.apache.tuscany.spi.extension.ReferenceTestCase, we have the
following test:
public void testPrepare() throws Exception {
TestReference ref = new TestReference(null, null, null);
try {
ref.prepare(); //[rfeng] We assume the assert will catch
null before it moves on to NPE
fail();
} catch (AssertionError e) {
//expected // [rfeng] NPE is thrown if assertion is not enabled
}
}
By default, assertions are disabled by JVM unless you explicitly
turned it on using -ea option on the VM (In Eclipse, you need to
set the VM arguments either at the JRE or test case.profile level.
For Maven, you may need to set MAVEN_OPTS to include -ea). As a
result, the test case fails because it throws NullPointerException
instead of AssertionError.
Should we improve these test cases to be more robust?
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java assertion related test case failures
We covered assertions a little in the exception handling document
which should be on the website but which I got from here:
http://svn.apache.org/viewvc/incubator/tuscany/site/src/site/xdoc/
exception_handling.html?view=co
To me, assertions are things that the developer declares should never
happen at runtime. As in, I thought about it and decided this could
never happen but I decided to check anyway as I could be wrong.
Enabling them when running tests is necessary to verify those
assumptions.
This is different from things that should not happen but which might
through user error - like checking for a user passing in a null value
to an API call and throwing a IllegalArgumentException rather than
letting a NPE happen when you use the value.
And different from things that might quite realistically go wrong and
which your user should be informed about - such as an IOException
when reading from a file.
--
Jeremy
On Jul 20, 2006, at 3:33 PM, Raymond Feng wrote:
For those who are interested, there's a nice article about java
assertions @ http://www.javaworld.com/javaworld/jw-11-2001/jw-1109-
assert.html. And the following is quoted from it:
Expressions within an assert statement should not produce side
effects, since doing so exposes program execution to potentially
different behavior with and without assertions enabled. You should
use assertions to produce more reliable programs, not less reliable
ones.
Finally, caution must guide the development of the expressions used
in assert statements. In addition to not producing side effects,
assertions should not alter normal program execution.
I think I buy what the author says.
Thanks,
Raymond
- Original Message - From: Yang ZHONG
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, July 20, 2006 3:11 PM
Subject: Re: Java assertion related test case failures
I hope our code are not designated to run in some specifically
configured
JVM.
Since JVMs may turn assertion on or off, I'm not sure
AssertionError should
be an expected behavior in general.
Dedicated exceptions and errors are much better protocol, e.g.
IndexOutOfBoundsException and OutOfMemoryError give much more
specific/useful info than plain AssertionError, not to mention
assertion
isn't really born for error reporting.
On 7/20/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
Assertions should be enabled when running our test cases.
I have added an AssertionTestCase to the spi module that will cause
the build to fail if assertions are not enabled.
--
Jeremy
On Jul 20, 2006, at 9:36 AM, Raymond Feng wrote:
Hi,
I ran into some test case failures with the trunk code in both
Eclipse and Maven (reported by my continumm build) related to the
usage of java assertions.
For example, in test case
org.apache.tuscany.spi.extension.ReferenceTestCase, we have the
following test:
public void testPrepare() throws Exception {
TestReference ref = new TestReference(null, null, null);
try {
ref.prepare(); //[rfeng] We assume the assert will catch
null before it moves on to NPE
fail();
} catch (AssertionError e) {
//expected // [rfeng] NPE is thrown if assertion is not
enabled
}
}
By default, assertions are disabled by JVM unless you explicitly
turned it on using -ea option on the VM (In Eclipse, you need to
set the VM arguments either at the JRE or test case.profile level.
For Maven, you may need to set MAVEN_OPTS to include -ea). As a
result, the test case fails because it throws NullPointerException
instead of AssertionError.
Should we improve these test cases to be more robust?
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java assertion related test case failures
If the purpose of the test case is to verify the assert, I suggest that we
use ClassLoader.setClassAssertionStatus(targetClassName, true) to make
sure assert is on before the target class is initialized (for example, in
a static block or TestCase.setUp()) instead of requesting the whole JVM to
be launched with -ea. Making sense?
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, July 20, 2006 4:00 PM
Subject: Re: Java assertion related test case failures
We covered assertions a little in the exception handling document which
should be on the website but which I got from here:
http://svn.apache.org/viewvc/incubator/tuscany/site/src/site/xdoc/
exception_handling.html?view=co
To me, assertions are things that the developer declares should never
happen at runtime. As in, I thought about it and decided this could
never happen but I decided to check anyway as I could be wrong. Enabling
them when running tests is necessary to verify those assumptions.
This is different from things that should not happen but which might
through user error - like checking for a user passing in a null value to
an API call and throwing a IllegalArgumentException rather than letting a
NPE happen when you use the value.
And different from things that might quite realistically go wrong and
which your user should be informed about - such as an IOException when
reading from a file.
--
Jeremy
On Jul 20, 2006, at 3:33 PM, Raymond Feng wrote:
For those who are interested, there's a nice article about java
assertions @ http://www.javaworld.com/javaworld/jw-11-2001/jw-1109-
assert.html. And the following is quoted from it:
Expressions within an assert statement should not produce side effects,
since doing so exposes program execution to potentially different
behavior with and without assertions enabled. You should use assertions
to produce more reliable programs, not less reliable ones.
Finally, caution must guide the development of the expressions used in
assert statements. In addition to not producing side effects, assertions
should not alter normal program execution.
I think I buy what the author says.
Thanks,
Raymond
- Original Message - From: Yang ZHONG
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, July 20, 2006 3:11 PM
Subject: Re: Java assertion related test case failures
I hope our code are not designated to run in some specifically
configured
JVM.
Since JVMs may turn assertion on or off, I'm not sure AssertionError
should
be an expected behavior in general.
Dedicated exceptions and errors are much better protocol, e.g.
IndexOutOfBoundsException and OutOfMemoryError give much more
specific/useful info than plain AssertionError, not to mention
assertion
isn't really born for error reporting.
On 7/20/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
Assertions should be enabled when running our test cases.
I have added an AssertionTestCase to the spi module that will cause
the build to fail if assertions are not enabled.
--
Jeremy
On Jul 20, 2006, at 9:36 AM, Raymond Feng wrote:
Hi,
I ran into some test case failures with the trunk code in both
Eclipse and Maven (reported by my continumm build) related to the
usage of java assertions.
For example, in test case
org.apache.tuscany.spi.extension.ReferenceTestCase, we have the
following test:
public void testPrepare() throws Exception {
TestReference ref = new TestReference(null, null, null);
try {
ref.prepare(); //[rfeng] We assume the assert will catch
null before it moves on to NPE
fail();
} catch (AssertionError e) {
//expected // [rfeng] NPE is thrown if assertion is not
enabled
}
}
By default, assertions are disabled by JVM unless you explicitly
turned it on using -ea option on the VM (In Eclipse, you need to
set the VM arguments either at the JRE or test case.profile level.
For Maven, you may need to set MAVEN_OPTS to include -ea). As a
result, the test case fails because it throws NullPointerException
instead of AssertionError.
Should we improve these test cases to be more robust?
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
Re: Java assertion related test case failures
Agree with Jeremy on assertion usage, especially *assertion is not anything
user should be informed about*
which is exactly my point: assertion (failure) should *not* be user/TestCase
expectation.
On 7/20/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
We covered assertions a little in the exception handling document
which should be on the website but which I got from here:
http://svn.apache.org/viewvc/incubator/tuscany/site/src/site/xdoc/
exception_handling.html?view=co
To me, assertions are things that the developer declares should never
happen at runtime. As in, I thought about it and decided this could
never happen but I decided to check anyway as I could be wrong.
Enabling them when running tests is necessary to verify those
assumptions.
This is different from things that should not happen but which might
through user error - like checking for a user passing in a null value
to an API call and throwing a IllegalArgumentException rather than
letting a NPE happen when you use the value.
And different from things that might quite realistically go wrong and
which your user should be informed about - such as an IOException
when reading from a file.
--
Jeremy
On Jul 20, 2006, at 3:33 PM, Raymond Feng wrote:
For those who are interested, there's a nice article about java
assertions @ http://www.javaworld.com/javaworld/jw-11-2001/jw-1109-
assert.html. And the following is quoted from it:
Expressions within an assert statement should not produce side
effects, since doing so exposes program execution to potentially
different behavior with and without assertions enabled. You should
use assertions to produce more reliable programs, not less reliable
ones.
Finally, caution must guide the development of the expressions used
in assert statements. In addition to not producing side effects,
assertions should not alter normal program execution.
I think I buy what the author says.
Thanks,
Raymond
- Original Message - From: Yang ZHONG
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, July 20, 2006 3:11 PM
Subject: Re: Java assertion related test case failures
I hope our code are not designated to run in some specifically
configured
JVM.
Since JVMs may turn assertion on or off, I'm not sure
AssertionError should
be an expected behavior in general.
Dedicated exceptions and errors are much better protocol, e.g.
IndexOutOfBoundsException and OutOfMemoryError give much more
specific/useful info than plain AssertionError, not to mention
assertion
isn't really born for error reporting.
On 7/20/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
Assertions should be enabled when running our test cases.
I have added an AssertionTestCase to the spi module that will cause
the build to fail if assertions are not enabled.
--
Jeremy
On Jul 20, 2006, at 9:36 AM, Raymond Feng wrote:
Hi,
I ran into some test case failures with the trunk code in both
Eclipse and Maven (reported by my continumm build) related to the
usage of java assertions.
For example, in test case
org.apache.tuscany.spi.extension.ReferenceTestCase, we have the
following test:
public void testPrepare() throws Exception {
TestReference ref = new TestReference(null, null, null);
try {
ref.prepare(); //[rfeng] We assume the assert will catch
null before it moves on to NPE
fail();
} catch (AssertionError e) {
//expected // [rfeng] NPE is thrown if assertion is not
enabled
}
}
By default, assertions are disabled by JVM unless you explicitly
turned it on using -ea option on the VM (In Eclipse, you need to
set the VM arguments either at the JRE or test case.profile level.
For Maven, you may need to set MAVEN_OPTS to include -ea). As a
result, the test case fails because it throws NullPointerException
instead of AssertionError.
Should we improve these test cases to be more robust?
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
Re: Java assertion related test case failures
If you like my previous proposal, here's the patch I tried.
Thanks,
Raymond
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, July 20, 2006 4:14 PM
Subject: Re: Java assertion related test case failures
If the purpose of the test case is to verify the assert, I suggest that
we use ClassLoader.setClassAssertionStatus(targetClassName, true) to
make sure assert is on before the target class is initialized (for
example, in a static block or TestCase.setUp()) instead of requesting the
whole JVM to be launched with -ea. Making sense?
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, July 20, 2006 4:00 PM
Subject: Re: Java assertion related test case failures
We covered assertions a little in the exception handling document which
should be on the website but which I got from here:
http://svn.apache.org/viewvc/incubator/tuscany/site/src/site/xdoc/
exception_handling.html?view=co
To me, assertions are things that the developer declares should never
happen at runtime. As in, I thought about it and decided this could
never happen but I decided to check anyway as I could be wrong.
Enabling them when running tests is necessary to verify those
assumptions.
This is different from things that should not happen but which might
through user error - like checking for a user passing in a null value to
an API call and throwing a IllegalArgumentException rather than letting
a NPE happen when you use the value.
And different from things that might quite realistically go wrong and
which your user should be informed about - such as an IOException when
reading from a file.
--
Jeremy
On Jul 20, 2006, at 3:33 PM, Raymond Feng wrote:
For those who are interested, there's a nice article about java
assertions @ http://www.javaworld.com/javaworld/jw-11-2001/jw-1109-
assert.html. And the following is quoted from it:
Expressions within an assert statement should not produce side
effects, since doing so exposes program execution to potentially
different behavior with and without assertions enabled. You should use
assertions to produce more reliable programs, not less reliable ones.
Finally, caution must guide the development of the expressions used in
assert statements. In addition to not producing side effects,
assertions should not alter normal program execution.
I think I buy what the author says.
Thanks,
Raymond
- Original Message - From: Yang ZHONG
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, July 20, 2006 3:11 PM
Subject: Re: Java assertion related test case failures
I hope our code are not designated to run in some specifically
configured
JVM.
Since JVMs may turn assertion on or off, I'm not sure AssertionError
should
be an expected behavior in general.
Dedicated exceptions and errors are much better protocol, e.g.
IndexOutOfBoundsException and OutOfMemoryError give much more
specific/useful info than plain AssertionError, not to mention
assertion
isn't really born for error reporting.
On 7/20/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
Assertions should be enabled when running our test cases.
I have added an AssertionTestCase to the spi module that will cause
the build to fail if assertions are not enabled.
--
Jeremy
On Jul 20, 2006, at 9:36 AM, Raymond Feng wrote:
Hi,
I ran into some test case failures with the trunk code in both
Eclipse and Maven (reported by my continumm build) related to the
usage of java assertions.
For example, in test case
org.apache.tuscany.spi.extension.ReferenceTestCase, we have the
following test:
public void testPrepare() throws Exception {
TestReference ref = new TestReference(null, null, null);
try {
ref.prepare(); //[rfeng] We assume the assert will catch
null before it moves on to NPE
fail();
} catch (AssertionError e) {
//expected // [rfeng] NPE is thrown if assertion is not
enabled
}
}
By default, assertions are disabled by JVM unless you explicitly
turned it on using -ea option on the VM (In Eclipse, you need to
set the VM arguments either at the JRE or test case.profile level.
For Maven, you may need to set MAVEN_OPTS to include -ea). As a
result, the test case fails because it throws NullPointerException
instead of AssertionError.
Should we improve these test cases to be more robust?
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
Re: Java assertion related test case failures
I'm not sure what happens to the continumm build which underneath runs maven. It seems that assertions are not enabled for the test cases by default and I have to set -ea in the mvn.bat so that the latest code can be built successfully. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, July 20, 2006 4:37 PM Subject: Re: Java assertion related test case failures On Jul 20, 2006, at 4:14 PM, Raymond Feng wrote: If the purpose of the test case is to verify the assert, I suggest that we use ClassLoader.setClassAssertionStatus (targetClassName, true) to make sure assert is on before the target class is initialized (for example, in a static block or TestCase.setUp()) instead of requesting the whole JVM to be launched with -ea. Making sense? I was thinking that when running testcases we want do assertions on across the entire VM so that any problems in peripheral classes would cause the test to fail. As in, all tests should pass if assertions are enabled so let's test that assumption so that we can't mistakenly run the tests with assertions off. IMO it is not a class-by-class thing. In the maven build assertions are enabled in the surefire plugin so tests should always run with them on. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java assertion related test case failures
These test cases were my bone-headed mistake...What they should be doing is testing that prepare() executes properly so I'll fix them once I get a couple of other checkins cleared out. That said, we really ought to run mvn was assertions on as we need to verify that assertion checking is done properly. For example, there have been times in the past when assertion checking was incorrectly done (i.e. threw errors for legitimate cases) and problems arose when someone ran with -ea. Jim On Jul 20, 2006, at 4:57 PM, Raymond Feng wrote: I'm not sure what happens to the continumm build which underneath runs maven. It seems that assertions are not enabled for the test cases by default and I have to set -ea in the mvn.bat so that the latest code can be built successfully. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, July 20, 2006 4:37 PM Subject: Re: Java assertion related test case failures On Jul 20, 2006, at 4:14 PM, Raymond Feng wrote: If the purpose of the test case is to verify the assert, I suggest that we use ClassLoader.setClassAssertionStatus (targetClassName, true) to make sure assert is on before the target class is initialized (for example, in a static block or TestCase.setUp()) instead of requesting the whole JVM to be launched with -ea. Making sense? I was thinking that when running testcases we want do assertions on across the entire VM so that any problems in peripheral classes would cause the test to fail. As in, all tests should pass if assertions are enabled so let's test that assumption so that we can't mistakenly run the tests with assertions off. IMO it is not a class-by-class thing. In the maven build assertions are enabled in the surefire plugin so tests should always run with them on. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
