james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara (JIRA)" <mime4j-...@james.apache.org>
Subject [jira] [Commented] (MIME4J-192) setFlatMode and setContentDecoding are not exposed by the MessageBuilder interface
Date Sun, 17 Apr 2011 11:34:05 GMT

    [ https://issues.apache.org/jira/browse/MIME4J-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020780#comment-13020780

Stefano Bagnara commented on MIME4J-192:

Sorry but I still don't understand. Even if I add 2 booleans to jDKIM Message.newMessageBuilder
I simply move the class cast from one method to another.

Ignoring jDKIM for a while and starting from mime4j MessageServiceFactory I can't find any
path to set flatmode/contentdecoding without class casting. 

The question is: how can I use mime4j DOM API to do flat parsing without content decoding
and without using class casting to mime4j internals? if I can't do this then the whole dom
api is useless for jDKIM use case and I will simply move to new MessageBuilderImpl() as it
doesn't make sense to use factories if I have to cast the result. I don't like this solution
but I just want a confirmation that this is the right thing to do in your opinion.

> setFlatMode and setContentDecoding are not exposed by the MessageBuilder interface
> ----------------------------------------------------------------------------------
>                 Key: MIME4J-192
>                 URL: https://issues.apache.org/jira/browse/MIME4J-192
>             Project: JAMES Mime4j
>          Issue Type: Improvement
>          Components: dom
>    Affects Versions: 0.7
>            Reporter: Stefano Bagnara
>             Fix For: 0.7
> Here is jDKIM use case:
> ----
>     public Message(InputStream is) throws IOException, MimeException {
>         MessageBuilder mb = newMessageBuilder();
>         if (mb instanceof MessageBuilderImpl) {
>         	((MessageBuilderImpl) mb).setFlatMode(true);
>         	((MessageBuilderImpl) mb).setContentDecoding(false);
>         }
>         org.apache.james.mime4j.dom.Message mImpl = mb.parse(new EOLConvertingInputStream(is));
>         this.message = mImpl;
>     }
> ----
> Is this the expected client pattern? Or should we expose setFlatMode and setContentDecoding
in the MessageBuilder interface so to remove the class casting requirement?

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message