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] Created: (MIME4J-158) Reduce usage of commons-logging. Remove it from low-level classes (packages)
Date Sat, 02 Jan 2010 21:41:54 GMT
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


CharsetDecoder uses a combination of fluent api (CharsetDecoder.onMalformedInput) with a CodingErrorAction
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.

View raw message