On 24/11/2008, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > On Mon, Nov 24, 2008 at 4:40 PM, sebb <[EMAIL PROTECTED]> wrote: > <snip/> > > > > > I've just seen the error again. > > I updated the fail() message to fail(e+e.getMessage()) so I got a bit > > more information: > > > > > ------------------------------------------------------------------------------- > > Test set: org.apache.commons.scxml.model.ModelTestSuite > > > ------------------------------------------------------------------------------- > > Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.876 > > sec <<< FAILURE! > > > testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest) > > Time elapsed: 0.125 sec <<< FAILURE! > > junit.framework.AssertionFailedError: java.lang.NullPointerExceptionnull > > at junit.framework.Assert.fail(Assert.java:47) > > at > org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:195) > > at > org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:171) > > at > org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:114) > > > > I think the fail(e.getMessage()) calls need to be updated to something > > more useful, as the current code swallows all the useful information. > > In test cases it's best to let the code throw an Exception - only > > expected throwables should be caught by test cases. > > > > <snap/> > > Yup, that pattern needs to be changed throughout the test cases. > > > > > I did this, and ran the test a few more times, and now I get: > > > > > ------------------------------------------------------------------------------- > > Test set: org.apache.commons.scxml.model.ModelTestSuite > > > ------------------------------------------------------------------------------- > > Tests run: 78, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.906 > > sec <<< FAILURE! > > > testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest) > > Time elapsed: 0.125 sec <<< ERROR! > > java.lang.NullPointerException > > at > org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:194) > > at > org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:181) > > at > org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:115) > > > > It looks like the testExecutorSerializability() method is returning > > null, though I'm not sure why as it appears the file is generated and > > read OK. I replaced the File I/O with ByteArray I/O and I did not get > > the error, though I did not test very many times > > > > When I run the test on 1.4.2, I get a lot of messages: > > SERIALIZATION ERROR: The DOM implementation in use is not serializable > > > > This is possibly because the DOM implementation is being provided by > > the JDK, as I don't get it with JDK 1.5.0 or 1.6.0. > > > > Does JDK 1.4.2 require additional dependencies? > > > > <snip/> > > No, its actually the other way around (for example, we require Xalan > for XPath support if its greater than 1.4). > > What you are seeing is probably more a statement about what xml-apis > Maven is using when running the tests (at some point they started > pegging the xml-api versions IIRC). >
Surely Maven will use either whatever the JDK provides or whatever the POM specifies? I did some more tests, and if I add xercesImpl and xml-apis to the dependencies, then Java 1.4.2 no longer reports any serialisation errors. This suggests that (some) Java 1.4.2 xml classes are not serialisable whereas Java 1.5.0+ are serialisable. Further, this suggests that SCXML will not be serialisable on Java 1.4 unless additional dependencies are provided. Have you not seen the serialisation errors when testing on Java 1.4.2? What is a bit odd is that the test error also seems to disappear when I add xerces and xml-apis. The method that fails already checks for serialisation problems. > > > I think the test suite should be improved to give more details if/when > > errors occur. At present errors are quite difficult to track down. > > > > <snap/> > > Agreed, as proven by this thread. We should track this via a JIRA > ticket (I suggest fix version v0.10) and subsequent improvements to > the tests, Javadoc and FAQ as necessary. > OK. > -Rahul > > --------------------------------------------------------------------- > 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]
