[
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