On Sun, Aug 24, 2008 at 12:49 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Stefano Bagnara ha scritto: >> >> Robert Burrell Donkin ha scritto: >>> >>> 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. >> >> Ok. I found the issue. Whenever in the protocol we have something similar: >> -------- >> C: A14 APPEND testmailbox {3661+} >> C: [a number of spaces] >> >> >> >> C: Delivered-To: [EMAIL PROTECTED] >> ------ >> Geronimo raised an IndexOutOfBoundException. >> >> If I remove the empty line everything works. >> >> Is it an issue in geronimo or is it malformed input? >> To fix this I guess I have to remove the empty line and subtract the line >> lenght from the number in brakets, right? >> Should I add 2 (CRLF) to the line length? > > I tried removing the empty lines and now I get this: > org.apache.james.test.functional.imap.ProtocolSession$InvalidServerResponseException: > Location: > /org/apache/james/test/functional/imap/scripts/SearchAtoms.test:1842 > LastClientMsg: A125 SEARCH SUBJECT o > Expected: '\* SEARCH 6 7 10 12 18 19' > Actual : '* SEARCH 6 7 10 12 17 18 19' > > Looking at the test source I see: > --- > C: A125 SEARCH SUBJECT o > # TODO: JavaMail's parsing is buggy. Replace with Mime4J. > # S: \* SEARCH 6 7 10 12 17 18 19 > S: \* SEARCH 6 7 10 12 18 19 > --- > > I then decided to switch back to sun's implementation to see results and I > have a pass on every test. > > So here it seems that geronimo parser is better in this case.
yes > THen I looked at the message #17 to understand why Javamail didn't correctly > parse the Subject and here is the snipped: > ------ > C: Subject: > C: =?windows-1256?Q?=5BInvitation=5D_Apach ... > C: =?windows-1256?Q?Fri_11_Apr_2008_=28=29?= > ------ > > I changed it to > ------ > C: Subject: =?windows-1256?Q?=5BInvitation=5D_Apach ... > C: =?windows-1256?Q?Fri_11_Apr_2008_=28=29?= > ------ > > And now it works with both sun's and geronimo's. > > I don't know if "Subject:" alone in a line is a valid header so I don't know > what implementation does the right thing here. IIRC that's a cpature of an actual wild email AIUI anything after the colon can be wrapped by adding CRLF and starting the next line with whitespace. if so then the header's legitimate. > Unless anyone object I plan to change the .test files so to avoid this cases > (empty line on top and new line after headername) and let both > implementations pass the test suite. i think the newline header is a bug but it's probably best to resolve this at the parser level. maybe we need to raise bug reports with sun and geronino about this parser corner case. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
