[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-195: ----------------------------------------- I'd suggest to leave the TurboFilter as it is right now since it saves the time needed to create the actual event. I always thought that this was a quite brilliant idea. Instead, why not define an additional EventFilter extension point to enable the desired behavior?

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

[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-195 at 3/19/10 1:41 PM: --------------------------------------------------------------- I think the only real downside for this change is that it modifies the turbo filter interface which will break turbo filters developed by the user. On the other hand, the encoder change already breaks compatibility in a major way. So its seems best to bundle this second breaking change into 0.9.19. I would like to avoid breaking things with each release. It will give us a nice API enabling TurboFilters to modify events without any impact on performance for the case where there are no turbo filters installed and a relatively small impact in the case there are one or more turbo filters. Moreover, the impact diminishes with each additional filter. was (Author: noreply.ceki@qos.ch): I think the only downside for this change is that it modifies the turbo filter interface which will break turbo filters developed by the user. On the other hand, the encoder change already breaks compatibility in a major way. So its seems best to bundle this second breaking change into 0.9.19. I would like to avoid breaking things with each release. It will give us a nice API enabling TurboFilters to modify events without any impact on performance for the case where there are no turbo filters installed and a relatively small impact in the case there are one or more turbo filters. Moreover, the impact diminishes with each additional filter.

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

[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-195: -------------------------------------- You are right. I was implicitly assuming that turbo filters(and only they) could modify logging events during a brief period. I am also assuming a two phase initialization mechanism for LoggingEvent, where in the initial phase the marker, logger, level, format, prams and the throwable would be set and available for read/write. Other parameters such as the timestamp and the MDC would be not be set nor be available for read/write. After the intervention of all the installed turbo filters, LoggingEvent would be fully initialized and *locked* before being handed over to the logger-level filter and if the event passes that hurdle, handed to the appropriate appenders. Does it make sense? What use case do you imagine for allowing modifications to loggingevent later on in the event processing lifecycle?

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

[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] Ralph Goers commented on LBCLASSIC-195: --------------------------------------- If this was a community where my vote mattered I would veto this with a -1. I wasn't aware that adding encoders breaks compatibility. If so then it needs to be redone so that it can still work without breaking existing configurations.

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

[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] Ralph Goers commented on LBCLASSIC-195: --------------------------------------- Absolutely not. Lots of people use FileAppender. Forcing them to change their configuration on a minor upgrade is terrible. Despite Logback's supposed 0.9.x beta state, this code has been in production in lots of places for quite a while. You could certainly do this on a new FileAppender, but not the existing one.

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

[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn edited comment on LBCLASSIC-195 at 3/19/10 3:20 PM: ------------------------------------------------------------------ I'm not very fond about forcing a change of config files, either. This could be avoided quite easily though, simply by keeping the layout-setter in appender and having <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>testFile.log</file> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%msg%n</pattern> </layout> </appender> initialize as if it were actually <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>testFile.log</file> <encoder> <pattern>%msg%n</pattern> </encode> </appender> i.e. wrapping the given layout into an appropriate LayoutWrappingEncoder and setting that to the appender. One could also emit a (deprecation) warning in that case but I see no reason why this behavior shouldn't be kept indefinitely. was (Author: jhuxhorn): I'm not very fond about forcing a change of config files, either. This could be avoided quite easily though, simply by keeping the layout-setter in appender and having <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>testFile.log</file> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%msg%n</pattern> </layout> </appender> initialize as if it where actually <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>testFile.log</file> <encoder> <pattern>%msg%n</pattern> </encode> </appender> i.e. wrapping the given layout into an appropriate LayoutWrappingEncoder and setting that to the appender. One could also emit a (deprecation) warning in that case but I see no reason why this behavior shouldn't be kept indefinitely.

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

[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-195 at 3/19/10 4:11 PM: --------------------------------------------------------------- Ralph, I hope you know by now that your opinion matters even without veto powers. The required changes to the config file are described at [1]. Basically, <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>testFile.log</file> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%msg%n</pattern> </layout> </appender> has to be changed to <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>testFile.log</file> <encoder> <pattern>%msg%n</pattern> </encode> </appender> Is that something you could live with? [1] http://logback.qos.ch/temp/codes.html#layoutInsteadOfEncoder was (Author: noreply.ceki@qos.ch): Ralph, I hope you know by now that your opinion matters even without veto powers. The required changes to the config file are described at [1]. Basically, <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>testFile.log</file> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%msg%n</pattern> </layout> </appender> has to be changed to <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>testFile.log</file> <encoder> <pattern>%msg%n</pattern> </encode> </appender> Is that something you could live with? [1] http://logback.qos.ch/temp/codes.html#layoutInsteadOfEncoder

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

[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] Rü edited comment on LBCLASSIC-195 at 3/19/10 5:55 PM: ------------------------------------------------------- So there is no breaking change in 0.9.19 because of http://jira.qos.ch/browse/LBCORE-128 any more, right? But I find it irritating to have logging events changed by filters... just looking at the names of the classes would suggest that an event will never change! And even more so, a filter should just say yea or nay and not go and fiddle with the stuff it receives. Maybe I'm currently just all too spoiled by Scala, but I find it irritating. What's the use case, anyway?!? I can't see one! Performance and compatibility concerns should follow the use case, shouldn't they. was (Author: rd): So there is no breaking change in 0.9.19 because of http://jira.qos.ch/browse/LBCORE-128 any more, right? I find it irritating to have logging events changed by filters... just looking at the names of the classes would suggest that an event will never change! And even more so, a filter should just say yea or nay and not go and fiddle with the stuff it receives. Maybe I'm currently just all too spoiled by Scala, but I find it irritating. What's the use case, anyway?!? I can't see one; aside from performance and compatibility concerns.

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

[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] 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

[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-195 at 3/22/10 10:29 PM: ---------------------------------------------------------------- You are right. I was implicitly assuming that turbo filters(and only they) could modify logging events during a brief period. I am also assuming a two phase initialization mechanism for LoggingEvent, where in the initial phase the marker, logger, level, format, prams and the throwable would be set and available for read/write. Other parameters such as the timestamp and the MDC would be not be set nor be available for read/write. After the intervention of all the registered turbo filters, and if the event passes the logger-level filter, only then would LoggingEvent be fully initialized and *locked* before being handed over the appropriate appenders. Does it make sense? What use case do you imagine for allowing modifications to loggingevent later on in the event processing life cycle? was (Author: noreply.ceki@qos.ch): You are right. I was implicitly assuming that turbo filters(and only they) could modify logging events during a brief period. I am also assuming a two phase initialization mechanism for LoggingEvent, where in the initial phase the marker, logger, level, format, prams and the throwable would be set and available for read/write. Other parameters such as the timestamp and the MDC would be not be set nor be available for read/write. After the intervention of all the installed turbo filters, and if the event passes the logger-level filter, only then would LoggingEvent be fully initialized and *locked* before being handed over the appropriate appenders. Does it make sense? What use case do you imagine for allowing modifications to loggingevent later on in the event processing lifecycle?

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

[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-195: -------------------------------------- While logback components can recursively invoke logback, this is discouraged. However, given that recursive invocation cannot be always avoided, it is tolerated. See my reply to Joern dated 19th of March [1]. As I imagine it, a turbo filter is authorized to modify/transform all LoggingEvent fields which are set at the time when the turbo filters are invoked. At a later stage, the LoggingEvent is locked and becomes read only. Ideally, a turbo filter should be able to add or remove events on the fly. However, I think the computational overhead would be quite substantial. Anyway, I'll soon write a prototype in a new branch so that we could have something more concrete to discuss. [1] http://jira.qos.ch/browse/LBCLASSIC-195?focusedCommentId=11643#action_11643

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

[ http://jira.qos.ch/browse/LBCLASSIC-195?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu resolved LBCLASSIC-195. ---------------------------------- Fix Version/s: 0.9.20 Resolution: Won't Fix It is just impossible to avoid LoggingEvent event creation and still allow TurboFilters to modify the event.

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 Fix For: 0.9.20

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