[logback-user] Handling log events happening before configuration is ready?

[Ralph Goers]

It sounds to me like what you want is to use the SiftingAppender using a SystemPropertyDiscriminator.

Ralph

On Sep 7, 2012, at 1:56 AM, Thorbjørn Ravn Andersen wrote:

> Hi Ceki.
> 
> Thank you for your prompt reply and a very interesting suggestion.
> 
> It sounds to me that what you suggest - which essentially tells logback to
> delay processing completely - require that our application will have to
> leave the "use only SLF4J" paradigm that we have been very satisfied with,
> and instead know the most intimates of intimate about not only logback but
> also our logging configuration (which is by definition here unknown to the
> programmer as it is the responsibility of the deployer - also we usually use
> the Simple implementation while developing thanks to the flexibility of
> Maven).  I am not sure I like going there.
> 
> Perhaps this is a bit overkill for our current needs?   A slightly smarter
> FileAppender might be better for us, perhaps?
> 
> I'll ponder some more, and have a look at the code - perhaps a devious
> workaround shows - has happended before :)
> 
> Thanks
> 
> /Thorbjørn
> 
> 
> -----Original Message-----
> From: logback-user-bounces at qos.ch [mailto:logback-user-bounces at qos.ch] On
> Behalf Of ceki
> Sent: 5. september 2012 15:34
> To: logback users list
> Subject: Re: [logback-user] Handling log events happening before
> configuration is ready?
> 
> 
> 
> On 05.09.2012 14:29, Thorbjørn Ravn Andersen wrote:
>> Very rapidly - usually within the first second.  We are still in the 
>> initialization phase of our application.
> 
> In that case, you could declare a buffer in logback.xml, buffer the events
> until all the initialization information is available, and then configure
> logback via another configuration file by invoking Joran directly as
> explained at
> 
>   http://logback.qos.ch/manual/configuration.html#joranDirectly
> 
> Once logback is configured a second time (and for good), you can replay the
> events contained in the buffer.
> 
> The initial Logback.xml could be as small as:
> 
> <configure>
>   <appender name="LIST" class="ch.qos.logback.core.read.ListAppender"/>
>   <root level="DEBUG">
>     <appender-ref ref="LIST"/>
>   </root>
> </configure>
> 
> 
> To obtain the appender named LIST:
> 
>   import ch.qos.logback.classic.Logger;
>   LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
>   Logger root = lc.getLogger(Logger.ROOT_NAME);
>   ListAppender listAppender = (ListAppender ) root.getAppender("LIST");
>   List<ILoggingEvent> eList = (List<ILoggingEvent>) listAppender.list;
> 
> 
> Unfortunately, logback-classic does not offer an API for replaying events.
> If however, you *know* that you have appenders A and B configured, you could
> write:
> 
>   Appender appenderA = root.getAppender("A")
>   Appender appenderB = root.getAppender("B")
> 
>   for(ILogdingEvent event: eList) {
>      appenderA.doAppend(event);
>      appenderB.doAppend(event);
>   }
> 
> 
> The main problem with this approach is that it requires the names of the
> appenders in your second logback config file to be hardcoded.
> However, there are ways to get around this limitation.
> 
> --
> Ceki
> http://tinyurl.com/proLogback
> 
>> 
>> -----Original Message-----
>> From: logback-user-bounces at qos.ch [mailto:logback-user-bounces at qos.ch] 
>> On Behalf Of ceki
>> Sent: 4. september 2012 14:50
>> To: logback users list
>> Subject: Re: [logback-user] Handling log events happening before 
>> configuration is ready?
>> 
>> How much time are we talking about between logback initialization and 
>> the time where the value of the property is known?
>> 
>> On 04.09.2012 14:38, Thorbjørn Ravn Andersen wrote:
>>> We have  done plain old “just log to a new file for the duration of 
>>> the program – delete old logs daily” for several years now and found 
>>> it works well for us.
>>> 
>>> Now I have a rather tricky situation where part of the file name to 
>>> be used by (a subclass of) FileAppender needs to be supplied by my 
>>> code, but the initialization phase of the application contains log 
>>> statements triggering the initialization of logback _/before/_ the 
>>> property referred to by the FileAppender name string is set causing 
>>> the log file to have an incorrect name.
>>> 
>>> Basically what I have found to be the behavior I want is for logback 
>>> to await opening the file and write data before I say it can.
>>> 
>>> Question is how I can do this within the limits of logback.  Can I 
>>> tell logback to just buffer events in memory (this will only be for a 
>>> few seconds, and memory will most likely not be an issue) – some kind 
>>> of valve?  Can I tell FileAppender to write to a temporary file and 
>>> rename it whenever the name is ready (perhaps using some of the 
>>> Policies from RollingFileAppender)?
>>> 
>>> Any suggestions on how to handle this?
>>> 
>>> Note:  As we restart our application daily we do not need 
>>> RollingFileAppender for our general logging – instead we have 
>>> subclassed FileAppender to remove “older than X days” files from the 
>>> target folder.  This has proven to work very well for our scenario.
>>> 
>>> Thanks
>>> 
>>> /Thorbjørn
>>> 
> 
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user
> 
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user