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.
