Why are encoder-less appenders not consistently allowed?
I have a need to dynamically adjust appenders at run-time to use a custom Layout. What I really want is to have encoder-less appenders set up (via the config file) and then add the appropriate LayoutWrappingEncoder programmatically. This works fine for a basic FileAppender. *However*, this fails for a ConsoleAppender, or (interestingly) for a FileAppender created dynamically by a SiftingAppender. (You get errors that an encoder has to be set and that the init method can't be invoked.) Is there a reason for this inconsistency? I suspect it might just be that there is inconsistent handling internally of when an appender is started(??). (I assume the init method that is being referred to in the error messages is start().) (The context is that this is logging from a simulation. I want all log messages to be prefixed with the simulation time, which is something that is only available within the application, and differs per logged message. I guess I could use a SimTime MDC key which is updated before each message logged, but that's a bit clumsy. Doing it generically inside a Layout, independent of the rest of the simulation code, is much better.) Stuart -- ________________________________ Stuart Rossiter
Using MDC would be the normal way. Just set your SimTime in the MDC each time you change configuration. Not sure how doing it in a custom injected Layout makes it any easer? -- View this message in context: http://logback.10977.n7.nabble.com/Why-are-encoder-less-appenders-not-consis... Sent from the Users mailing list archive at Nabble.com.
On 16 April 2013 15:25, diroussel <nabble@diroussel.xsmail.com> wrote:
Using MDC would be the normal way. Just set your SimTime in the MDC each time you change configuration.
Not sure how doing it in a custom injected Layout makes it any easer?
Well, it's a much cleaner code design my way (IMO). At decreasing levels of bad design, I could: (a) Add the simulation time within each message explicitly e.g. logger.info(formatSimTime() + "My widget was wangled"); [horrible 'leakage' into each logging call] (b) Add it in a global logging function: e.g. myLogging.info("My widget was wangled"); [takes the standard SLF4J interface away from the coder, and they have to remember to use this wrapper. Also always means the sim time is after any other Logback pattern fields in the log, when I really want this to act as a replacement for the commonly-used system time field] (c) Set MDC before each call and then extract that via the pattern layout [Same leakage into the code as (b), though fixes the time position in the message. Messy because I am partitioning logs by thread as well, also using MDC values. Will also be bombarding Logback with new MDC values.] (d) Use a custom layout that adds the sim time transparently to the code [Chosen solution. This can't be set up in the Logback config file because the layout requires references to internal simulation objects to get the simulation time. Hence my requirement to create an appender (via sifting appender for the per-thread separation) either without an encoder (ideally) or with a dummy one, and then set up the encoder programmatically at run-time initialisation]
Stuart, If you do one simulation per thread, then you can put what you need in a ThreadLocal, then use a Custome Converter to read from the ThreadLocal and get the SimTime. See http://logback.qos.ch/manual/layouts.html#customConversionSpecifier If that is not enough ... Would it be possible to implement what you want if (http://jira.qos.ch/browse/LOGBACK-719 "Provide a mechanism to specify an appender factory class") were implemented? I've not reviewed the associated changes, so I'm not sure, but you could have a look. If they look good and you test them out and it works for you, then that's more reason for those changes to be accepted into logback. David -- View this message in context: http://logback.10977.n7.nabble.com/Why-are-encoder-less-appenders-not-consis... Sent from the Users mailing list archive at Nabble.com.
On 19 April 2013 13:58, diroussel <nabble@diroussel.xsmail.com> wrote:
Stuart,
If you do one simulation per thread, then you can put what you need in a ThreadLocal, then use a Custome Converter to read from the ThreadLocal and get the SimTime.
See http://logback.qos.ch/manual/layouts.html#customConversionSpecifier
David, Ah, yes, nice. ThreadLocal use would avoid the issue of not having access to per-simulation objects from outside the simulation. I'll have a look at refactoring to that when I have some time. Thanks, Stuart
participants (2)
-
diroussel -
Stuart Rossiter