[ 
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

       
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev

Reply via email to