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 12:30:10 GMT

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

Stefano Bagnara commented on MIME4J-192:

Oleg: i'm sorry but I didn't want to touch the mime4j code as you already complained enough
about my dom refactorings, so I just wanted to understand what was the right solution. Of
course I could have added the 2 attributes myself if you simply replied "the current api doesn't
have a solution, we can add this feature by adding an attribute in the implementation".

I don't agree with you about "flatmode" being an implementation detail. Flat mode tells the
parser to adopt a different behaviour and return a different result. Is an interface detail
(it alters the type of result you get from parse), not an implementation one. That said I'm
fine anyway now that after r1094132 I can refactor jDKIM against trunk.

> 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