james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukáš Vlček <lukas.vl...@gmail.com>
Subject Re: Switching from 0.6 to 0.7.1 - address parsing, CRLF issues
Date Thu, 15 Dec 2011 10:41:01 GMT
Hi,

I tried it and it works. Thanks!

However, still I am not sure if this fixed everything.
See the following commit in my test repo on github (I added a new branch
called "workaround")
https://github.com/lukas-vlcek/mime4j-test/commit/385c66847bec4393ad67069fb367c174f87c5656

As you can see the call to  message.getFrom().get(0).getName() returns
expected data, but message.getHeader().getField("from").getBody() does not.
At least that is how I understand its JavaDoc:
http://james.apache.org/mime4j/apidocs/org/apache/james/mime4j/stream/Field.html#getBody()

"Gets the unparsed and possibly encoded (see RFC 2047) field body string."

How should I understand the "encoded" in this context?

Sorry for being too nitpicking, but Mime4J is quite important for me and
migration from 0.6 to 0.7.x turned out to be more challenging then I had
hoped for.

Regards,
Lukas

On Mon, Dec 12, 2011 at 4:27 PM, Lukáš Vlček <lukas.vlcek@gmail.com> wrote:

> Thanks, I will give it a try.
> Cheers,
> Lukas
>
>
> On Mon, Dec 12, 2011 at 4:23 PM, Oleg Kalnichevski <olegk@apache.org>wrote:
>
>> On Mon, 2011-12-12 at 16:05 +0100, Lukáš Vlček wrote:
>> > Hi,
>> >
>> > On Mon, Dec 12, 2011 at 3:58 PM, Oleg Kalnichevski <olegk@apache.org>
>> wrote:
>> >
>> > > On Mon, 2011-12-12 at 15:24 +0100, Lukáš Vlček wrote:
>> > > > Done,
>> > > >
>> > > > Please feel free to update the issues
>> > > > https://issues.apache.org/jira/browse/MIME4J-210 as I did not want
>> to
>> > > > invent my own terminology for this bug.
>> > > > BTW When can I expect 0.7.2 to be released? Fix of this issue is
>> quite
>> > > > important for me.
>> > > >
>> > > > Regards,
>> > > > Lukas
>> > > >
>> > >
>> > > In my personal opinion this issue is nowhere near being severe enough
>> to
>> > > warrant an emergency release. One can fairly easily work the problem
>> > > around by using the standard strict field parser or a custom field
>> > > parser.
>> > >
>> >
>> > Are there any example how to do that? Which API do I need to use?
>> >
>>
>> ---
>> InputStream instream = getInputStream("mbox/jbpm-users-01.mbox");
>> try {
>>    FieldParser<MailboxListField> mailboxListParser =
>> MailboxListFieldImpl.PARSER;
>>    LenientFieldParser fieldParser = new LenientFieldParser();
>>    fieldParser.setFieldParser(FieldName.FROM, mailboxListParser);
>>    fieldParser.setFieldParser(FieldName.RESENT_FROM,
>> mailboxListParser);
>>
>>    DefaultMessageBuilder messageBuilder = new DefaultMessageBuilder();
>>    messageBuilder.setFieldParser(fieldParser);
>>
>>    Message message = messageBuilder.parseMessage(instream);
>>
>>    assertEquals("jiacc@gillion.com.cn",
>> message.getFrom().get(0).getName());
>>
>> } finally {
>>    instream.close();
>> }
>> ---
>>
>> Oleg
>>
>> >
>> > >
>> > > I cannot say when 0.7.2 could be expected. It very much depends on the
>> > > one who volunteers to be a release manager for it.
>> > >
>> > > Oleg
>> > >
>> > > > On Mon, Dec 12, 2011 at 3:09 PM, Oleg Kalnichevski <
>> olegk@apache.org>
>> > > wrote:
>> > > >
>> > > > > On Mon, 2011-12-12 at 14:44 +0100, Lukáš Vlček wrote:
>> > > > > > Hi,
>> > > > > >
>> > > > > > is it ok if I point the JIRA issue to my github repo for
>> references?
>> > > Or
>> > > > > do
>> > > > > > you want me to implement use case directly in mime4j? (I
can do
>> > > that, it
>> > > > > > will just take longer :-)
>> > > > > >
>> > > > >
>> > > > > The problem is quite trivial to reproduce. So, makes no big
>> difference
>> > > > > to me.
>> > > > >
>> > > > > Oleg
>> > > > >
>> > > > >
>> > > > > > Thanks,
>> > > > > > Lukas
>> > > > > >
>> > > > > > On Mon, Dec 12, 2011 at 2:37 PM, Oleg Kalnichevski <
>> olegk@apache.org
>> > > >
>> > > > > wrote:
>> > > > > >
>> > > > > > > On Mon, 2011-12-12 at 10:46 +0100, Lukáš Vlček wrote:
>> > > > > > > > Hi Oleg,
>> > > > > > > >
>> > > > > > > > Thanks for reply. I would love to open JIRA tickets,
but I
>> am
>> > > still
>> > > > > not
>> > > > > > > > sure that I use Mime4J API correctly. So I prepared
a
>> simple test
>> > > > > case
>> > > > > > > and
>> > > > > > > > uploaded to GitHub.
>> > > > > > > > It contains some tests to demonstrate mentioned
issues:
>> > > > > > > >
>> > > > > > > > Specifically, the following two tests are about
encoding of
>> > > "From"
>> > > > > field.
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > >
>> > >
>> https://github.com/lukas-vlcek/mime4j-test/blob/master/src/test/java/org/mime4j/test/BasicTest.java#L20
>> > > > > > > > and
>> > > > > > > >
>> > > > > > >
>> > > > >
>> > >
>> https://github.com/lukas-vlcek/mime4j-test/blob/master/src/test/java/org/mime4j/test/BasicTest.java#L28
>> > > > > > > >
>> > > > > > > > Do you think you can take a look at this and tell
me if I
>> use
>> > > Mime4J
>> > > > > API
>> > > > > > > > correctly, if so then I will be happy to go and
open JIRA
>> > > tickets.
>> > > > > > > >
>> > > > > > > > Best regards,
>> > > > > > > > Lukas
>> > > > > > > >
>> > > > > > >
>> > > > > > > I can confirm this issue is caused by a regression
in mime4j
>> 0.7.x.
>> > > > > > > Basically the lenient address parser does not decode
encoded
>> > > display
>> > > > > > > names at all. Please raise a JIRA for this regression.
>> > > > > > >
>> > > > > > > Oleg
>> > > > > > >
>> > > > > > > > On Fri, Dec 9, 2011 at 2:20 PM, Oleg Kalnichevski
<
>> > > olegk@apache.org>
>> > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > On Wed, 2011-12-07 at 16:50 +0100, Lukáš
Vlček wrote:
>> > > > > > > > > > Hi,
>> > > > > > > > > >
>> > > > > > > > > > First of all, thanks for this library!
>> > > > > > > > > >
>> > > > > > > > > > I am new to this list, but I have been
using mime4j for
>> some
>> > > > > time now
>> > > > > > > > > (but
>> > > > > > > > > > I would not call myself an expert on
it though).
>> > > > > > > > > >
>> > > > > > > > > > I switched from 0.6 to 0.7.1 recently
and my tests
>> started to
>> > > > > fail in
>> > > > > > > > > some
>> > > > > > > > > > cases:
>> > > > > > > > > >
>> > > > > > > > > > 1) Parsing address:
>> > > > > > > > > >
>> > > > > > > > > > I have this in the mail header:
>> > > > > > > > > > From: "=?utf-8?B?amlhY2NAZ2lsbGlvbi5jb20uY24=?="
<
>> > > > > > > jiacc@gillion.com.cn>
>> > > > > > > > > >
>> > > > > > > > > > in 0.6 I was able to have it parsed
into: "
>> > > jiacc@gillion.com.cn<
>> > > > > > > > > > jiacc@gillion.com.cn>"
>> > > > > > > > > > I am unable to get the same result with
0.7.1
>> > > > > > > > > >
>> > > > > > > > > > Another similar example is:
>> > > > > > > > > > From: =?GBK?B?x67T7rrn?= <yhqian99@163.com>
>> > > > > > > > > >
>> > > > > > > > > > in 0.6 it was giving me: "钱宇虹
<yhqian99@163.com>"
>> > > > > > > > > > in 0.7.1 I can not get it.
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > 2) CRLF instead of LF
>> > > > > > > > > >
>> > > > > > > > > > In body texts I am getting CRLF (\r\n)
where I was
>> getting LF
>> > > > > (\n)
>> > > > > > > with
>> > > > > > > > > 0.6
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > More generally, is there anything in
particular I
>> should pay
>> > > > > > > attention to
>> > > > > > > > > > when switching from 0.6 to 0.7.1 ?
>> > > > > > > > > >
>> > > > > > > > > > Regards,
>> > > > > > > > > > Lukas
>> > > > > > > > >
>> > > > > > > > > Lukas
>> > > > > > > > >
>> > > > > > > > > If you are reasonably sure mime4j does not
correctly parse
>> > > certain
>> > > > > MIME
>> > > > > > > > > messages please open raise a JIRA for each
case
>> separately and
>> > > > > provide
>> > > > > > > a
>> > > > > > > > > sample message  in binary format (as an attachment)
and a
>> test
>> > > case
>> > > > > > > > > reproducing the issue.
>> > > > > > > > >
>> > > > > > > > > Oleg
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > >
>> > >
>> > >
>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message