[
https://issues.apache.org/jira/browse/MIME4J-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830174#action_12830174
]
Oleg Kalnichevski commented on MIME4J-158:
------------------------------------------
Folks,
I got rid of all dependencies on Commons-Logging other than LoggingMonitor. I
would very much rather prefer to remove this class as well. Please let me know
if there are any objections to not depending on a particular logging toolkit.
Oleg
> 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.
