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.
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.
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
