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

[Thorbjørn Ravn Andersen]

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