[
https://issues.apache.org/jira/browse/MIME4J-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed MIME4J-278.
---------------------------------
Resolution: Fixed
> DefaultAddressBuilderTest fails when parsing non-ASCII characters in address
> line
> ---------------------------------------------------------------------------------
>
> Key: MIME4J-278
> URL: https://issues.apache.org/jira/browse/MIME4J-278
> Project: James Mime4j
> Issue Type: Bug
> Components: dom
> Affects Versions: 0.8.2
> Reporter: Dmitry Katsubo
> Priority: Minor
>
> I observe non-consistent behaviour of {{DefaultAddressBuilderTest}} in the
> place it tries to parse non-ASCII address line:
> {code:java}
> Tests run: 19, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.001 sec
> <<< FAILURE! - in
> org.apache.james.mime4j.field.address.DefaultAddressBuilderTest
> testParseMailbox(org.apache.james.mime4j.field.address.DefaultAddressBuilderTest)
> Time elapsed: 0.001 sec <<< ERROR!
> org.apache.james.mime4j.field.address.ParseException: Lexical error at line
> 1, column 8. Encountered: "\u0413" (1043), after : ""
> at
> org.apache.james.mime4j.field.address.DefaultAddressBuilderTest.testParseMailbox(DefaultAddressBuilderTest.java:65)
> Caused by: org.apache.james.mime4j.field.address.TokenMgrError: Lexical error
> at line 1, column 8. Encountered: "\u0413" (1043), after : ""
> at
> org.apache.james.mime4j.field.address.DefaultAddressBuilderTest.testParseMailbox(DefaultAddressBuilderTest.java:65)
> {code}
> This test fails when I run Maven from command-line, and passes OK when I run
> it from Eclipse. I suspect that this test is system-codepage dependant, in
> particular:
> * This execution works just fine:
> {{mvn -DargLine="-Dfile.encoding=UTF8" clean install}}
> * This execution fails with above message:
> {{mvn -DargLine="-Dfile.encoding=CP1251" clean install}}
> It would be difficult to fix the issue in test as
> {{DefaultAddressParser.DEFAULT}} is created before any static initializers
> are executed, but probably the problem is in implementation as parser should
> work consistent independently of {{file.encoding}} value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
