[
https://issues.apache.org/jira/browse/MIME4J-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020781#comment-13020781
]
Oleg Kalnichevski commented on MIME4J-192:
------------------------------------------
For the sake of sweet Jesus, Stefano, if you miss a particular configuration
parameter in MessageServiceFactoryImpl, just go ahead and add it! What is the
point of polluting an abstract interface with implementation specific details,
when the whole problem can be better solved by changing a few lines in an impl
class?
Please see http://svn.apache.org/viewvc?rev=1094132&view=rev
Oleg
> 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
