You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by rd...@apache.org on 2008/08/24 12:16:18 UTC
svn commit: r688490 - in
/james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets:
RemoteDeliveryTest.java StandardRemoteDeliveryTestable.java
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
Removed:
james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets/RemoteDeliveryTest.java
james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets/StandardRemoteDeliveryTestable.java
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r688490 - in /james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets: RemoteDeliveryTest.java StandardRemoteDeliveryTestable.java
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Aug 24, 2008 at 12:25 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Sun, Aug 24, 2008 at 12:10 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
>>>>
>>>> On Sun, Aug 24, 2008 at 11:33 AM, Stefano Bagnara <ap...@bago.org>
>>>> wrote:
>>>>>
>>>>> rdonkin@apache.org 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: robertburrelldonkin@gmail.com
> ------
> Geronimo raised an IndexOutOfBoundException.
>
> If I remove the empty line everything works.
>
> Is it an issue in geronimo or is it malformed input?
it's malformed input (i had some issues with the script generation
which is now resolved)
however, since javamail copes, there's an argument that geronimo
should too. throwing IndexOfBoundsException sounds like a bug to me.
> To fix this I guess I have to remove the empty line and subtract the line
> lenght from the number in brakets, right?
yes
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r688490 - in /james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets: RemoteDeliveryTest.java StandardRemoteDeliveryTestable.java
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Aug 24, 2008 at 4:54 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Sun, Aug 24, 2008 at 12:49 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> 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.
>
> Adding a space after the colon fixed the javamail parsing. I didn't have the
> time to check the mime grammar to understand if this is a bug or not.
it's not really clear in the specification. subject is unstructured so
some may argue not. it does happen in the wild though.
IIRC we discussed something similar with mime4j - what to do about
incorrect headers
>>> 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.
>
> https://issues.apache.org/jira/browse/GERONIMO-4261
javamail?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r688490 - in /james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets:
RemoteDeliveryTest.java StandardRemoteDeliveryTestable.java
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sun, Aug 24, 2008 at 12:49 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> 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.
Adding a space after the colon fixed the javamail parsing. I didn't have
the time to check the mime grammar to understand if this is a bug or not.
>> 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.
https://issues.apache.org/jira/browse/GERONIMO-4261
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r688490 - in /james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets: RemoteDeliveryTest.java StandardRemoteDeliveryTestable.java
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Aug 24, 2008 at 12:49 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Stefano Bagnara ha scritto:
>>
>> Robert Burrell Donkin ha scritto:
>>>
>>> On Sun, Aug 24, 2008 at 12:10 PM, Stefano Bagnara <ap...@bago.org>
>>> wrote:
>>>>
>>>> Robert Burrell Donkin ha scritto:
>>>>>
>>>>> On Sun, Aug 24, 2008 at 11:33 AM, Stefano Bagnara <ap...@bago.org>
>>>>> wrote:
>>>>>>
>>>>>> rdonkin@apache.org 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: robertburrelldonkin@gmail.com
>> ------
>> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r688490 - in /james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets:
RemoteDeliveryTest.java StandardRemoteDeliveryTestable.java
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> Robert Burrell Donkin ha scritto:
>> On Sun, Aug 24, 2008 at 12:10 PM, Stefano Bagnara <ap...@bago.org>
>> wrote:
>>> Robert Burrell Donkin ha scritto:
>>>> On Sun, Aug 24, 2008 at 11:33 AM, Stefano Bagnara <ap...@bago.org>
>>>> wrote:
>>>>> rdonkin@apache.org 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: robertburrelldonkin@gmail.com
> ------
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r688490 - in /james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets:
RemoteDeliveryTest.java StandardRemoteDeliveryTestable.java
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sun, Aug 24, 2008 at 12:10 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Sun, Aug 24, 2008 at 11:33 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> rdonkin@apache.org 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: robertburrelldonkin@gmail.com
------
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?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r688490 - in /james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets: RemoteDeliveryTest.java StandardRemoteDeliveryTestable.java
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Aug 24, 2008 at 12:10 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Sun, Aug 24, 2008 at 11:33 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> rdonkin@apache.org 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r688490 - in /james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets:
RemoteDeliveryTest.java StandardRemoteDeliveryTestable.java
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sun, Aug 24, 2008 at 11:33 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> rdonkin@apache.org 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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r688490 - in /james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets: RemoteDeliveryTest.java StandardRemoteDeliveryTestable.java
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Aug 24, 2008 at 11:33 AM, Stefano Bagnara <ap...@bago.org> wrote:
> rdonkin@apache.org 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.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r688490 - in /james/server/sandbox/active/sample-independent-imap/server/mailets-function/src/test/java/org/apache/james/transport/mailets:
RemoteDeliveryTest.java StandardRemoteDeliveryTestable.java
Posted by Stefano Bagnara <ap...@bago.org>.
rdonkin@apache.org 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?
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...
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org