Timing of sifting appender dynamic appender instantiation
The manual states that appenders get dynamically added by SiftingAppender when the relevant MDC key is altered: "Whenever the "userid" MDC key is assigned a new value, a new FileAppender instance will be built from scratch." However, I found that it was only created when I logged my first message using a relevant Logger. (And confirmed this by using an OnConsoleStatusListener in my configuration file.) Is this a bug? A documentation error? This is a problem because I need to programmatically adjust this appender (from the 'base' set up by the configuration file) before I use it. I currently have to log a spurious message first so that the appender is created, and then adjust it. Stuart -- ________________________________ Stuart Rossiter
I'm using logback 1.0.9 and this works for me. When I set an MDC key, then the very next log statement will cause it to go to a new appender and new log file. What do you mean that you need to send a spurious message first? David -- View this message in context: http://logback.10977.n7.nabble.com/Timing-of-sifting-appender-dynamic-append... Sent from the Users mailing list archive at Nabble.com.
On 11 April 2013 14:34, diroussel <nabble@diroussel.xsmail.com> wrote:
I'm using logback 1.0.9 and this works for me.
When I set an MDC key, then the very next log statement will cause it to go to a new appender and new log file.
Yes, this does happen for me as well. What I mean is that Logback only adds the appender dynamically *within the log statement method*, rather than as soon as the MDC key is set. This is a problem for me because I want to amend the dynamically created appender (replacing the encoder with my own) *before* logging anything. As in my original msg, the wording in the manual strongly suggests that the appender is created at MDC put-time, and so is misleading. It would also seem more 'correct' to support use cases like mine. (There's also a secondary issue: currently one *must* specify an encoder in the config file for the dynamically created sub-appender. It would be better if one could omit the encoder when one knew that one was adding one's own, avoiding the unnecessary initialisation. It perhaps also fits better conceptually: an appender will just do nothing until an encoder is added, rather than requiring the full 'stack' of appender-->encoder-->layout before being able to start.)
What do you mean that you need to send a spurious message first?
I log a message to actually trigger the sub-appender addition. (I don't want to do this since it is using an encoder which I don't want to use.) Hope that makes it clearer!
David
Many thanks for the response anyway.
Stuart, I understand what you mean now. It definately creates the dynamic appender on append. I've been reading the source that does that, SiftingAppenderBase, today looking at another issue. I can see why it wouldn't make sense to ido it in MDC.put(). Maybe there is another way? I take if your encoder is dynamic, so can't be specified in logback.xml. - Maybe you can do it with a logback.groovy file, I've heard that is more flexible. - Maybe you could define many appenders, one for each encoder, and then use a filter to control which one the event goes to? - Maybe you could use a variable name in the encoder class name, which is replaced by the sifter before the appender is created? Annoyingly SiftingApender only works on one key at a time, so this might not work for you. David -- View this message in context: http://logback.10977.n7.nabble.com/Timing-of-sifting-appender-dynamic-append... Sent from the Users mailing list archive at Nabble.com.
On 11 April 2013 15:53, diroussel <nabble@diroussel.xsmail.com> wrote:
Stuart,
I understand what you mean now. It definately creates the dynamic appender on append. I've been reading the source that does that, SiftingAppenderBase, today looking at another issue.
I can see why it wouldn't make sense to ido it in MDC.put(). Maybe there is another way?
I take if your encoder is dynamic, so can't be specified in logback.xml.
- Maybe you can do it with a logback.groovy file, I've heard that is more flexible.
- Maybe you could define many appenders, one for each encoder, and then use a filter to control which one the event goes to?
- Maybe you could use a variable name in the encoder class name, which is replaced by the sifter before the appender is created? Annoyingly SiftingApender only works on one key at a time, so this might not work for you.
David
It would be less annoying if the addition occurred before active logging levels were checked, because then I could log a dummy TRACE level message to get things started. Unfortunately, I have to log something that actually gets logged, so have to use ERROR level to be safe. I don't think your last two possibilities will fly in my case, because my encoder has run-time 'things' in it (so it can't be instantiated via any kind of default constructor). Anyway, I have a simple-ish workaround, and may investigate more (incl. looking at the Logback source) when/if I have time. Thanks, Stuart
participants (2)
-
diroussel -
Stuart Rossiter