[logback-user] Handling log events happening before configuration is ready?
ceki
ceki at qos.ch
Wed Sep 5 15:33:38 CEST 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 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
>>
More information about the Logback-user
mailing list