Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Message-ID: <800419760.257971268609007174.JavaMail.jira@brutus.apache.org>
Date: Sun, 14 Mar 2010 23:23:27 +0000 (UTC)
From: "Stefano Bagnara (JIRA)" <mime4j-dev@james.apache.org>
To: mime4j-dev@james.apache.org
Subject: [jira] Commented: (MIME4J-175) Introduce a
 MessageBuilderFactory/MessageBuilder along the lines of
 DocumentBuilderFactory
In-Reply-To: <1468247253.257911268608647431.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Stefano Bagnara commented on MIME4J-175:
----------------------------------------

I committed a first draft similar to what DocumentBuilderFactory/DocumentBuilder do.

If you like the idea then we should extend this to support real world use cases:
1) Use of custom StorageProvider (maybe a generic setFeature(String key, Object value) in the MessageBuilderFactory).
2) Behaviour configuration (DecodeMonitor and MimeEntityConfig stuff exposed in the MessageBuilderFactory).
3) Message abstract class should expose methods to create bodies and fields.

Furthermore we could move the ServiceLoader util to a lower package and use that also for the Parser and for the StorageProvider selection.

WDYT?

> Introduce a MessageBuilderFactory/MessageBuilder along the lines of DocumentBuilderFactory
> ------------------------------------------------------------------------------------------
>
>                 Key: MIME4J-175
>                 URL: https://issues.apache.org/jira/browse/MIME4J-175
>             Project: JAMES Mime4j
>          Issue Type: Improvement
>          Components: dom
>    Affects Versions: 0.6
>            Reporter: Stefano Bagnara
>            Assignee: Stefano Bagnara
>             Fix For: 0.7
>
>
> This factory will support using the dom interfaces without knowledge of the "message" package.
> Implementing a simple java SPI for the factory will let us to decouple "dom" from "message" and leave more future extensibility.
> Then we'll have to add body/fields creation methods to Message.
> Message should be traversable and alterable directly from the api.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.