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

5 Sep 2012

      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@qos.ch [mailto:logback-user-bounces@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