james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <mime4j-...@james.apache.org>
Subject [jira] Updated: (MIME4J-158) Reduce usage of commons-logging in favor of a "Monitor" service.
Date Thu, 04 Feb 2010 15:36:28 GMT

     [ https://issues.apache.org/jira/browse/MIME4J-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Oleg Kalnichevski updated MIME4J-158:

    Attachment: MIME4J-158-stream.patch

The patch eliminates dependency on commons-logging in 'stream' classes


> Reduce usage of commons-logging in favor of a "Monitor" service.
> ----------------------------------------------------------------
>                 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.7
>         Attachments: MIME4J-158-stream.patch
> 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.

View raw message