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 Bernd Fondermann <bf...@brainlounge.de> on 2006/03/25 13:29:37 UTC
Latest commits & Unit Tests
Hi Stefano,
since your last commits, some unit tests are no longer succeeding on my
local trunk. two are easy fixes, but with the first one i am not so
sure...
Bernd
### MimeMessage*Test
"expected:<...Cp1252...> but was:<...ISO-8859-1...>"
impl seems to be platform specific and does fail on my unix env.
is there a generic solution to this?
this failure occurs in all of these:
MimeMessageCopyOnWriteProxyTest
MimeMessageFromSharedStreamTest
MimeMessageFromStreamTest
MimeMessageTest
MimeMessageFromMimeMessageTest
MimeMessageWrapperTest
### org.apache.james.core.MailImplTest
getSize() behavior has been changed in MailImpl, so we have to adjust here:
Index: src/test/org/apache/james/core/MailImplTest.java
===================================================================
--- src/test/org/apache/james/core/MailImplTest.java (revision 388495)
+++ src/test/org/apache/james/core/MailImplTest.java (working copy)
@@ -68,7 +68,7 @@
MailImpl mail = new MailImpl(name, senderMailAddress,
recepients, mimeMessage);
helperTestInitialState(mail);
- helperTestMessageSize(mail, mimeMessage.getSize()); //
MockMimeMessage default is -1 (accord. to javax.mail javadoc)
+ helperTestMessageSize(mail, 0);
assertEquals("initial message", mimeMessage.getMessageID(),
mail.getMessage().getMessageID());
assertEquals("sender", sender, mail.getSender().toString());
assertEquals("name", name, mail.getName());
### org.apache.james.remotemanager.RemoteManagerTest
I propose the following change to become platform independent:
Index: src/test/org/apache/james/remotemanager/RemoteManagerTest.java
===================================================================
--- src/test/org/apache/james/remotemanager/RemoteManagerTest.java
(revision 388495)
+++ src/test/org/apache/james/remotemanager/RemoteManagerTest.java
(working copy)
@@ -54,6 +54,8 @@
public class RemoteManagerTest extends TestCase {
+ public static final String LINE_SEPARATOR =
System.getProperties().getProperty("line.separator");
+
protected int m_remoteManagerListenerPort =
Util.getRandomNonPrivilegedPort();
protected RemoteManager m_remoteManager;
protected RemoteManagerTestConfiguration m_testConfiguration;
@@ -118,13 +120,13 @@
fail("reading remote manager answer failed");
}
-
allAnswerLines.addAll(Arrays.asList(stringBuffer.toString().split("\r\n")));
+
allAnswerLines.addAll(Arrays.asList(stringBuffer.toString().split(LINE_SEPARATOR)));
if ("".equals(getLastLine(allAnswerLines)))
allAnswerLines.remove(allAnswerLines.size()-1);
return allAnswerLines;
}
protected void sendCommand(String command) throws IOException {
- m_writer.write(command + "\r\n");
+ m_writer.write(command + LINE_SEPARATOR);
m_writer.flush();
}
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Wildcard MX
Posted by Stefano Bagnara <ap...@bago.org>.
Philip Tomlinson wrote:
> I got my ISP to set up a wildcard DNS MX entry for me.
> Consequently I can now ping anything.anything.pot.co.nz.
Ping and MX DNS entries are totally unrelated.
you "consequently" doesn't seem appropriate.
> I can also send emails from Yahoo mail to any subdomain of my domain and
> they are happily fetched by james fetchmail.
> However when I send from Google mail I get the error.
Where James is involved in the relay problem from google to your pop?
> -----------------
> Delivery to the following recipient failed permanently:
>
> phil@anything.pot.co.nz <ma...@pot.co.nz.remindme.pot.co.nz>
>
> Technical details of permanent failure:
> PERM_FAILURE: SMTP Error (state 9): 550-zproxy.gmail.com
> <http://550-zproxy.gmail.com> [64.233.162.197 <http://64.233.162.197>]
> is currently not permitted to relay
> 550-through this server. Perhaps you have not logged into the pop/imap
> server
> 550-in the last 30 minutes or do not have SMTP Authentication turned on
> in your
> 550 email client.
> ------------------
>
> Would anyone know why gmail would not be permitting this email to relay?
The error seems explicit: "Perhaps you have not logged into the pop/imap
server in the last 30 minutes or do not have SMTP Authentication
turned on in your email client.".
If understand your problem, James is not involved at all in your relay
problem. If you have further problems you should post them to a gmail
group/forum/list.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Wildcard MX
Posted by Philip Tomlinson <ph...@pot.co.nz>.
Hi,
I have a question about wildcard MX DNS addressing.
I got my ISP to set up a wildcard DNS MX entry for me.
Consequently I can now ping anything.anything.pot.co.nz.
I can also send emails from Yahoo mail to any subdomain of my domain and
they are happily fetched by james fetchmail.
However when I send from Google mail I get the error.
-----------------
Delivery to the following recipient failed permanently:
phil@anything.pot.co.nz <ma...@pot.co.nz.remindme.pot.co.nz>
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 9): 550-zproxy.gmail.com
<http://550-zproxy.gmail.com> [64.233.162.197 <http://64.233.162.197>]
is currently not permitted to relay
550-through this server. Perhaps you have not logged into the pop/imap
server
550-in the last 30 minutes or do not have SMTP Authentication turned on
in your
550 email client.
------------------
Would anyone know why gmail would not be permitting this email to relay?
Rgds,
Phil
-------------------------
Philip Tomlinson
PJT Consulting
Email: phil@pot.co.nz
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Latest commits & Unit Tests
Posted by Stefano Bagnara <ap...@bago.org>.
I saw the problem too.
I've had no time to investigate on this: the idea to assign them
incrementally could work.
Please submit a patch if you fix this succesfully!
Thank you,
Stefano
Bernd Fondermann wrote:
> I made the observation that arbitrary tests seem to fail on random, but
> rare occasions.
> when I simply re-run them, they pass.
> have others seen that, too?
>
> maybe this is due to the random assignment of unpriviledged ports but
> I'm not totally sure.
> if we would assign ports incrementally from the given range maybe we can
> reproduce such problems. should we try that?
>
> Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Latest commits & Unit Tests
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Stefano Bagnara wrote:
> Bernd Fondermann wrote:
>
> The AddFooter mailet should keep the charset of the mail, so adding the
> euro char in the footer should result in =A4 when the original mail is
> iso-8859-15 and =80 when the original mail is cp1252.
>
> Let me know if this works now.
runs fine now.
I made the observation that arbitrary tests seem to fail on random, but
rare occasions.
when I simply re-run them, they pass.
have others seen that, too?
maybe this is due to the random assignment of unpriviledged ports but
I'm not totally sure.
if we would assign ports incrementally from the given range maybe we can
reproduce such problems. should we try that?
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Latest commits & Unit Tests
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> Sorry to write that, but I updated to your AddFooter patch ;-) -- and
> got what seems to be a new one of the old one...
This is really weird: I checked the code and it seems correct: It passes
also if I set different standard encodings for my environment.
Maybe your environment don't understand correctly the cp1252 charset: I
changed the test to work on unicode chars and the iso-8859-15 charset.
I used the euro char in my test because it has 2 different codes in
cp1252 and iso-8859-15 charsets: 0x80 in cp1252 and 0xA4 in iso-8859-15.
The AddFooter mailet should keep the charset of the mail, so adding the
euro char in the footer should result in =A4 when the original mail is
iso-8859-15 and =80 when the original mail is cp1252.
Let me know if this works now.
> Testcase: testAddFooterTextPlainCP1252toISO8859 took 0.005 sec
> FAILED
> expected:<...80...> but was:<...A4...>
> junit.framework.ComparisonFailure: expected:<...80...> but was:<...A4...>
> [...]
> Except from that, all tests pass. Thanks a lot for doing the fixes!
>
> Bernd
Thank you for your help!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Latest commits & Unit Tests
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Sorry to write that, but I updated to your AddFooter patch ;-) -- and
got what seems to be a new one of the old one...
Testcase: testAddFooterTextPlainCP1252toISO8859 took 0.005 sec
FAILED
expected:<...80...> but was:<...A4...>
junit.framework.ComparisonFailure: expected:<...80...> but was:<...A4...>
at
org.apache.james.transport.mailets.AddFooterTest.testAddFooterTextPlainCP1252toISO8859(AddFooterTest.java:219)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Testcase: testAddFooterTextPlainCP1252toISO8859Testcase:
testAddFooterMultipartAlternative took 0.007 sec
Except from that, all tests pass. Thanks a lot for doing the fixes!
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Latest commits & Unit Tests
Posted by Stefano Bagnara <ap...@bago.org>.
You convinced me ;-)
I'll commit your patch asap.
Stefano
> Keeping a failing test would require meta-knowledge whether a test is
> 'supposed' to fail or not. all unit tests would soon become outdated and
> useless. the big merit of JUnit is you get a binary information after
> running the test. only 'green' can be a good result.
> so, i would suggest to add a test which is passing now, related in a
> comment to the JIRA in question and which fails as soon as the fix is
> applied so the test can be changed accordingly.
>
> Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Latest commits & Unit Tests
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Stefano Bagnara wrote:
> Bernd Fondermann wrote:
>
>> ### org.apache.james.core.MailImplTest
>>
>> getSize() behavior has been changed in MailImpl, so we have to adjust
>> here:
>
>
> Yes, I saw this but I didn't fix it because I was not sure the new
> behaviour was better than the previous.
> I think we can safely change it to 0.
+1
>
>> - helperTestMessageSize(mail, mimeMessage.getSize()); //
>> MockMimeMessage default is -1 (accord. to javax.mail javadoc)
>> + helperTestMessageSize(mail, 0);
>>
>> ### org.apache.james.remotemanager.RemoteManagerTest
>>
>> I propose the following change to become platform independent:
>
>
> IIRC this is a known bug of James. new lines in the telnet based tcp/ip
> protocols like SMTP and POP3 should always be CRLF (system indipendent).
> So the correct test is \r\n while we have a bug under linux where our
> protocols uses only \n
> We evaluated the use of MINA to resolve this issue too, but MINA SSL
> suport requires java 5...
>
> I'm not sure wether we should keep the failing test to remember the
> issue or we should fix the test for the known bug: what do you think?
Keeping a failing test would require meta-knowledge whether a test is
'supposed' to fail or not. all unit tests would soon become outdated and
useless. the big merit of JUnit is you get a binary information after
running the test. only 'green' can be a good result.
so, i would suggest to add a test which is passing now, related in a
comment to the JIRA in question and which fails as soon as the fix is
applied so the test can be changed accordingly.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Latest commits & Unit Tests
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> since your last commits, some unit tests are no longer succeeding on my
> local trunk. two are easy fixes, but with the first one i am not so
> sure...
Thank you Bernd for your test/help!
> ### MimeMessage*Test
>
> "expected:<...Cp1252...> but was:<...ISO-8859-1...>"
>
> impl seems to be platform specific and does fail on my unix env.
> is there a generic solution to this?
Understood.
I added a weird default locale to my junit test run and I'm able to
reproduce the issue.
I'll try to make the test code locale independent.
> this failure occurs in all of these:
> MimeMessageCopyOnWriteProxyTest
> MimeMessageFromSharedStreamTest
> MimeMessageFromStreamTest
> MimeMessageTest
> MimeMessageFromMimeMessageTest
> MimeMessageWrapperTest
>
> ### org.apache.james.core.MailImplTest
>
> getSize() behavior has been changed in MailImpl, so we have to adjust here:
Yes, I saw this but I didn't fix it because I was not sure the new
behaviour was better than the previous.
I think we can safely change it to 0.
> - helperTestMessageSize(mail, mimeMessage.getSize()); //
> MockMimeMessage default is -1 (accord. to javax.mail javadoc)
> + helperTestMessageSize(mail, 0);
>
> ### org.apache.james.remotemanager.RemoteManagerTest
>
> I propose the following change to become platform independent:
IIRC this is a known bug of James. new lines in the telnet based tcp/ip
protocols like SMTP and POP3 should always be CRLF (system indipendent).
So the correct test is \r\n while we have a bug under linux where our
protocols uses only \n
We evaluated the use of MINA to resolve this issue too, but MINA SSL
suport requires java 5...
I'm not sure wether we should keep the failing test to remember the
issue or we should fix the test for the known bug: what do you think?
> + public static final String LINE_SEPARATOR =
> System.getProperties().getProperty("line.separator");
> [..]
> -
> allAnswerLines.addAll(Arrays.asList(stringBuffer.toString().split("\r\n")));
>
> +
> allAnswerLines.addAll(Arrays.asList(stringBuffer.toString().split(LINE_SEPARATOR)));
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org