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] Commented: (MIME4J-158) Reduce usage of commons-logging in favor of a "Monitor" service.
Date Sun, 03 Jan 2010 21:50:54 GMT

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

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

I introduced a DecodeMonitor class with an "isListening" method and a "warn" method.
isListening is there for optimization reasons (the same as isLogEnabled).
warn can do logging or whatever and then return true if the monitor should result in a blocking
exception or false if it can be ignored.
DecodeMonitor already publish 2 static versions:
SILENT: not listening and ignore warnings
STRICT: listening and returning true to every warn call (resulting in a block).


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


Mime
View raw message