[logback-dev] [JIRA] Commented: (LBCLASSIC-195) Allow TurboFilters to modify events

[Rü (JIRA)]

    [ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11655#action_11655 ] 

Rü commented on LBCLASSIC-195:
------------------------------

Maybe I'm just nit-picking, but doesn't the DuplicateMessageFilter *suppress* the repetition of a message and issue a *new* event instead? It may wrap the suppressed message's contents, but it's still a new event, isn't it? BTW it could also wait until a different message comes in or a timeout occurs or something like that, and then introduce a "message [x] repeated [n] times" event, resetting the counter. Then it would even be *two* new events! The first event would be "starting to suppress message [x] due to frequency (for [y] seconds|for the rest of the day|until a different event occurs|forever|...)".

For the obfuscation use case, I'd first like to issue a warning that it's not a perfect solution to rely on the correct configuration of the logging system to not print this kind information... turbo filters in particular. It would be better to wrap such objects in an object that doesn't hold sensitive data; but while this is the safest thing the caller can do, that's a lot of work for her! If the data you don't want to be logged is not that sensitive and/or is already properly protected by encryption, etc., an alternative policy may be sufficient: Simply require the toString method of such objects to not include any sensitive data. In this way you only have to make sure that the argument is not serialized in any way other than as a String.

I still think that a filter is not a catalyst, so it should never touch the things it sees.

> Allow TurboFilters to modify events
> -----------------------------------
>
>                 Key: LBCLASSIC-195
>                 URL: http://jira.qos.ch/browse/LBCLASSIC-195
>             Project: logback-classic
>          Issue Type: Improvement
>          Components: Other
>            Reporter: Ceki Gulcu
>            Assignee: Ceki Gulcu
>            Priority: Blocker
>
> http://qos.ch/pipermail/logback-dev/2010-March/005290.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira