Sorry just checked, there was a change in MsgParserSpecsAsTest file. D.
On Fri, Nov 13, 2009 at 7:20 PM, Richard Hirsch <[email protected]> wrote: > 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 >>> >> >
