On Sun, Aug 24, 2008 at 12:10 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> >> On Sun, Aug 24, 2008 at 11:33 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >>> >>> [EMAIL PROTECTED] ha scritto: >>>> >>>> Author: rdonkin >>>> Date: Sun Aug 24 03:16:15 2008 >>>> New Revision: 688490 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=688490&view=rev >>>> Log: >>>> Trying again to get rid of tests that fail on my machine >>> >>> Have you any suggestion on how to deal with this in trunk? >> >> my current plan is to push forward with pulling out IMAP so that we >> can separate these two different concerns >> >>> Currently the m2-geronimo build on hudson works fine but fails on some >>> IMAP >>> test: >>> >>> >>> http://hudson.zones.apache.org/hudson/view/James/job/james-server-trunk-m2-geronimo/ws/trunk/phoenix-deployment/target/surefire-reports/org.apache.james.experimental.imapserver.ExperimentalSearchTest.txt >>> >>> e.g: >>> >>> testSearchAtomsUS(org.apache.james.experimental.imapserver.ExperimentalSearchTest) >>> Time elapsed: 4.386 sec <<< ERROR! >>> >>> org.apache.james.test.functional.imap.ProtocolSession$InvalidServerResponseException: >>> Location: >>> /org/apache/james/test/functional/imap/scripts/SearchAtoms.test:480 >>> LastClientMsg: >>> Expected: '\* 10 EXISTS' >>> Actual : 'A13 BAD APPEND failed. Illegal arguments.' >>> at >>> >>> org.apache.james.test.functional.imap.ProtocolSession$ServerResponse.checkResponse(ProtocolSession.java:304) >>> at >>> >>> org.apache.james.test.functional.imap.ProtocolSession$ServerResponse.testProtocol(ProtocolSession.java:285) >>> at >>> >>> org.apache.james.test.functional.imap.ProtocolSession.runSessions(ProtocolSession.java:86) >>> at >>> >>> org.apache.james.test.functional.imap.AbstractProtocolTest.runSessions(AbstractProtocolTest.java:100) >>> at >>> >>> org.apache.james.test.functional.imap.AbstractSimpleScriptedTestProtocol.scriptTest(AbstractSimpleScriptedTestProtocol.java:68) >>> at >>> >>> org.apache.james.test.functional.imap.AbstractTestSearch.testSearchAtomsUS(AbstractTestSearch.java:33) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>> at java.lang.reflect.Method.invoke(Method.java:585) >>> at junit.framework.TestCase.runTest(TestCase.java:154) >>> at junit.framework.TestCase.runBare(TestCase.java:127) >>> 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.GeneratedMethodAccessor24.invoke(Unknown Source) >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>> at java.lang.reflect.Method.invoke(Method.java:585) >>> at >>> >>> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) >>> at >>> >>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java: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:585) >>> at >>> >>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:334) >>> at >>> >>> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:980) >>> >>> >>> I cannot reproduce this one in my local machine, too, but this seems to >>> be >>> reproducible 100% of times in hudson. This seems to be related to >>> geronimo >>> classes, but there is no geronimo stuff in the stack and I don't know >>> that >>> code... maybe you get some hint from the stack above... >> >> the IMAP specification insists that errors are returned to the user. >> it probably shouldn't be a BAD but a NO and the details should be >> better. revision of the error handling is on my TODO list but ATM >> debugging requires the server log. most likely, geronimo can't parse >> correctly one of the mails. in the medium term, i'd like to strip out >> the coupling to mail and just use streams. this will result in >> improved performance and a more robust solution but this is related to >> ideas about next generation spooling so i wanted to move IMAP out >> first. >> >> i think it would be best to comment out the failure on trunk (with big >> TODOs) and continue with the geronimo trial. i'll take a look once the >> code's committed. > > You are right, it's a parsing issue. > > I've been able to reproduce the issue here (after upgrading eclipse and > m2eclipse) and it is an IndexOutOfBoundException in the MimeMessage. > I'll try to understand what kind of message make geronimo fail and change it > a bit to make our testsuite pass and file an issue to the geronimo tracker.
it'll be the message that is being appended (A13) however, the test suites are generated and reuse messages so you're likely to find other tests that fail. some of the messages are intentionally constructed to ensure that IMAP functions are correctly exercised. so i would probably recommend commenting out failing tests until the geronimo bug is fixed rather than patching the messages. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
