[jira] Commented: (MIME4J-158) Reduce usage of commons-logging in favor of a "Monitor" service.

["Stefano Bagnara (JIRA)" <mi...@james.apache.org>]

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

Stefano Bagnara commented on MIME4J-158:
----------------------------------------

The patch looks good. IMO you can work in CTR instead of RTC. We are not concurrently working on the same code so at most we'll revert if the committed code doesn't pass the review!

> 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.