Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Message-ID: <1739945265.7631262468514658.JavaMail.jira@brutus.apache.org>
Date: Sat, 2 Jan 2010 21:41:54 +0000 (UTC)
From: "Stefano Bagnara (JIRA)" <mime4j-dev@james.apache.org>
To: mime4j-dev@james.apache.org
Subject: [jira] Created: (MIME4J-158) Reduce usage of commons-logging.
 Remove it from low-level classes (packages)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Reduce usage of commons-logging. Remove it from low-level classes (packages)
----------------------------------------------------------------------------

                 Key: MIME4J-158
                 URL: https://issues.apache.org/jira/browse/MIME4J-158
             Project: JAMES Mime4j
          Issue Type: Improvement
    Affects Versions: 0.6
            Reporter: Stefano Bagnara
            Assignee: Stefano Bagnara
            Priority: Minor
             Fix For: 0.8


We should remove commons-logging usage from mime4j. At least starting from low level utilities and libraries.

The solution could be in some code reorganization and the introduction of a "monitorservice" passed to the various methods around the code.
The "monitorservice" could also be used to "alter" the strictness/lenientness of the parsing/decoding operations.

----

CharsetDecoder uses a combination of fluent api (CharsetDecoder.onMalformedInput) with a CodingErrorAction parameter.
CodingErrorAction is a simple enumeration (IGNORE, REPLACE, REPORT) and allow some methods to return CoderResult that is an object describing the various conditions (error/malformed/underflow/overflow/unmappable)

Another approach, instead, is the ErrorHandler from SAX: ErrorHandler expose the error/fatalError/warning methods, and all of them has a SAXParseException parameter, containing a message and a "locator".

We need both:
- a way to control how to deal with malformed/unexpected data (IGNORE/REPLACE/REPORT)
- a way to log malformations and their positions in the stream/field (like SAX ErrorHandler).

Maybe introducing a mixed service handling both use-cases is the best approach: basically a service that tells wether to "ignore", or "report", and if "report" then in the reporting methods it could alter the behaviour.
E.g: decoding QuotedPrintable we could ignore bad =XX sequences or leave them as is in output. For both cases we should be able to intercept and log the fact, or stop the processing with an IoException.


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