If you look at the console message from the last build (http://hudson.zones.apache.org/hudson/job/ESME/lastBuild/console), you do a see an error but a different one than Ethan mentioned. What is strange is that I have never seen this error during my local builds.
Even stranger is that Hudson says the test was successful. If you look at the difference between build 4 (http://hudson.zones.apache.org/hudson/job/ESME/4/console) and 5 (http://hudson.zones.apache.org/hudson/job/ESME/5/console), you will see that the exceptions come with the changes that occurred between 4 and 5. According to Hudson (http://hudson.zones.apache.org/hudson/job/ESME/5/), the only changes were David's new test cases. What is weird is that the exceptions occur in the MsgParserSpecsAsTest where no changes occured. The exception is below. @Ethan: By the way, I haven't checked in your API tests, because of the problems mentioned in my email from Nov. 9 ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.apache.esme.AppTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec Running org.apache.esme.lib.MsgParserSpecsAsTest 2009-11-13 12:23:37.902::INFO: Logging to STDERR via org.mortbay.log.StdErrLog 2009-11-13 12:23:37.969::INFO: jetty-6.1.21 2009-11-13 12:23:38.036::INFO: Started [email protected]:8989 org.apache.maven.surefire.booter.SurefireExecutionException: null; nested exception is java.lang.ExceptionInInitializerError: null java.lang.ExceptionInInitializerError at org.apache.esme.lib.MsgParserSpecsAsTest.<init>(MsgParseTest.scala:44) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.specs.runner.JUnitSuiteRunner.testSuite(JUnitSuiteRunner.scala:37) at org.specs.runner.JUnitSuiteRunner.run(JUnitSuiteRunner.scala:45) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) 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:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Caused by: java.lang.NullPointerException: Looking for Connection Identifier ConnectionIdentifier(lift) but failed to find either a JNDI data source with the name lift or a lift connection manager with the correct name On Fri, Nov 13, 2009 at 7:03 PM, Ethan Jewett <[email protected]> wrote: > When I do "mvn test" on my system, it bails out. The error message is > below. It looks to me like it is not working on Hudson either, if you > look at the test results trend on the following page: > http://hudson.zones.apache.org/hudson/job/ESME/ > > With regard to running tests on Hudson, I think failing tests are > perfect, but the tests need to run through without exceptions (they > can fail, but they can't have uncaught exceptions ... I think) or they > will severely reduce the usability of the test suite and of the Hudson > integration. Is that right? > > Thanks, > Ethan > > Error from my system: > > 2009-11-13 13:00:38.505::WARN: failed [email protected]:8989: > java.net.BindException: Address already in use > 2009-11-13 13:00:38.505::WARN: failed ser...@65861e41: > java.net.BindException: Address already in use > org.apache.maven.surefire.booter.SurefireExecutionException: null; > nested exception is java.lang.ExceptionInInitializerError: null > java.lang.ExceptionInInitializerError > at org.apache.esme.api.ApiSpecsAsTest.<init>(ApiTest.scala:43) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at > org.specs.runner.JUnitSuiteRunner.testSuite(JUnitSuiteRunner.scala:37) > at org.specs.runner.JUnitSuiteRunner.run(JUnitSuiteRunner.scala:45) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) > at org.apache.maven.surefire.Surefire.run(Surefire.java:177) > 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:338) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) > Caused by: java.net.BindException: Address already in use > at java.net.PlainSocketImpl.socketBind(Native Method) > at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365) > at java.net.ServerSocket.bind(ServerSocket.java:319) > at java.net.ServerSocket.<init>(ServerSocket.java:185) > at java.net.ServerSocket.<init>(ServerSocket.java:141) > at > org.mortbay.jetty.bio.SocketConnector.newServerSocket(SocketConnector.java:80) > at org.mortbay.jetty.bio.SocketConnector.open(SocketConnector.java:73) > at > org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:283) > at > org.mortbay.jetty.bio.SocketConnector.doStart(SocketConnector.java:147) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at org.mortbay.jetty.Server.doStart(Server.java:235) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at org.apache.esme.JettyTestServer$.start(JettySetup.scala:64) > at org.apache.esme.api.ApiSpecs$.<init>(ApiTest.scala:47) > at org.apache.esme.api.ApiSpecs$.<clinit>(ApiTest.scala) > ... 19 more > [INFO] > ------------------------------------------------------------------------ > [ERROR] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] There are test failures. > > Please refer to > /Users/esjewett/svn_repos/esme/trunk/server/target/surefire-reports > for the individual test results. > > > On Fri, Nov 13, 2009 at 11:32 AM, David Pollak > <[email protected]> wrote: >> On Fri, Nov 13, 2009 at 6:50 AM, Ethan Jewett <[email protected]> wrote: >> >>> Hi, >>> >>> It looks like these tests got checked in even though they don't run as >>> yet. Can they be commented out until they are operational? Currently >>> they are causing the full test run to fail, which is not the end of >>> the world but is something we should probably avoid. >>> >> >> The code I checked into the ESME SVN repo does run. >> >> If there is a problem running these tests, please let me know what the >> output is. >> >> >>> >>> Ethan >>> >>> On Tue, Nov 10, 2009 at 7:04 PM, David Pollak >>> <[email protected]> wrote: >>> > Folks, >>> > >>> > I started writing some ESME tests and got very cranky with Lift's TestKit >>> > (what kind of fool wrote those APIs anyway... oh, look, here's a mirror >>> and >>> > I'm looking at the fool). >>> > >>> > I spent a couple of hours cleaning up the Lift TestKit APIs so that tests >>> > will look like: >>> > >>> > "Login" in { >>> > for{ >>> > login <- post("/api/login", "token" -> token) !@ "Failed to log >>> in" >>> > if (testSuccess(login)) >>> > status <- login.get("/api/status") !@ "Failed to get status" if >>> > (testSuccess(status)) >>> > } { >>> > (status.xml \ "user" \ "@id").text must_== theUser.id.toString >>> > } >>> > } >>> > >>> > Once the Lift changes get approved and propagated, I'll post up the new >>> API >>> > test code. >>> > >>> > I plan to spend more time in ESME-land on Thursday and will get some of >>> the >>> > user edit and OpenID stuff finished. >>> > >>> > Thanks, >>> > >>> > David >>> > >>> > PS -- What's the ETA for the new templates? >>> > >>> > >>> > -- >>> > Lift, the simply functional web framework http://liftweb.net >>> > Beginning Scala http://www.apress.com/book/view/1430219890 >>> > Follow me: http://twitter.com/dpp >>> > Surf the harmonics >>> > >>> >> >> >> >> -- >> Lift, the simply functional web framework http://liftweb.net >> Beginning Scala http://www.apress.com/book/view/1430219890 >> Follow me: http://twitter.com/dpp >> Surf the harmonics >> >
