Handling log events happening before configuration is ready?
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
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
-- Ceki http://tinyurl.com/proLogback
Hi Ceki, When I first discovered logback about two years ago I saw this potential problem. I thought some sort of cyclic buffer as used by logback's status listener was a possible solution. The problem I saw was that filters, formatters and encoders were not set. Thus the logging event had to be stored in a 'raw' format (loggingEvent or something similar was sufficient) to be replayed back in an orderly manner, once the configuration of logback was complete. From memory, it was the orderly replay that I was yet to fully solve and the transition from a cyclic buffer to the effective logger as described in the configuration file. I could see the scenario where application, upon startup, had not yet fully finished establishing it's environment yet third party libraries are emitting crucial log statements. Some sort of buffer is needed. In most case it should not be needed. It raises another question; "How to configure this temporary buffer?" Brett Walker On 04/09/2012, at 10:50 PM, "ceki" <ceki@qos.ch> wrote:
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
-- Ceki http://tinyurl.com/proLogback _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
I guess you could have your logback configuration file just specify the log file name as "preconfig.log", then have your code create a new appender with the right filename and replace the current file appender. You'd end up with a very small preconfig.log (which your code might even be able to rename to your new name before pointing logback at it) and the rest of the days logs would be in your newly configured file. (*Chris*) On Tue, Sep 4, 2012 at 6:30 AM, Brett Walker <brett.walker@geometryit.com>wrote:
Hi Ceki,
When I first discovered logback about two years ago I saw this potential problem. I thought some sort of cyclic buffer as used by logback's status listener was a possible solution. The problem I saw was that filters, formatters and encoders were not set. Thus the logging event had to be stored in a 'raw' format (loggingEvent or something similar was sufficient) to be replayed back in an orderly manner, once the configuration of logback was complete. From memory, it was the orderly replay that I was yet to fully solve and the transition from a cyclic buffer to the effective logger as described in the configuration file.
I could see the scenario where application, upon startup, had not yet fully finished establishing it's environment yet third party libraries are emitting crucial log statements.
Some sort of buffer is needed. In most case it should not be needed.
It raises another question; "How to configure this temporary buffer?"
Brett Walker
On 04/09/2012, at 10:50 PM, "ceki" <ceki@qos.ch> wrote:
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
-- Ceki http://tinyurl.com/proLogback _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
If I'm not mistaken this is more or less the same issue I was describing in the thread "Context configuration during webapp loading". The problem is that the static initialization and default configuration of logback is triggered by the first time something uses slf4j to get a Logger factory org.slf4j.impl.StaticLoggerBinder init method. At the very least, you must trigger this initialization yourself by the code you must use to get the LoggerContext to do customization in a second *configuation*. It seems to me logback ought to offer a way to inject code into this static initialization, so that you can customize this *first* configuration. This would probably have to happen by a static method on some logback class involved in the initialization, and would require you to ensure your static code runs before any other static code but this would at least be an improvement IMO. Eric On 9/4/2012 11:40 AM, Chris Pratt wrote:
I guess you could have your logback configuration file just specify the log file name as "preconfig.log", then have your code create a new appender with the right filename and replace the current file appender. You'd end up with a very small preconfig.log (which your code might even be able to rename to your new name before pointing logback at it) and the rest of the days logs would be in your newly configured file. (*Chris*)
On Tue, Sep 4, 2012 at 6:30 AM, Brett Walker <brett.walker@geometryit.com <mailto:brett.walker@geometryit.com>> wrote:
Hi Ceki,
When I first discovered logback about two years ago I saw this potential problem. I thought some sort of cyclic buffer as used by logback's status listener was a possible solution. The problem I saw was that filters, formatters and encoders were not set. Thus the logging event had to be stored in a 'raw' format (loggingEvent or something similar was sufficient) to be replayed back in an orderly manner, once the configuration of logback was complete. From memory, it was the orderly replay that I was yet to fully solve and the transition from a cyclic buffer to the effective logger as described in the configuration file.
I could see the scenario where application, upon startup, had not yet fully finished establishing it's environment yet third party libraries are emitting crucial log statements.
Some sort of buffer is needed. In most case it should not be needed.
It raises another question; "How to configure this temporary buffer?"
Brett Walker
On 04/09/2012, at 10:50 PM, "ceki" <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
> 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 >> >> > > > -- > Ceki > http://tinyurl.com/proLogback > _______________________________________________ > Logback-user mailing list > Logback-user@qos.ch <mailto:Logback-user@qos.ch> > http://mailman.qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list Logback-user@qos.ch <mailto:Logback-user@qos.ch> http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Sorry I accidentally left half of another sentence in there which garbled things. Here is my last post again without the garbling: If I'm not mistaken this is more or less the same issue I was describing in the thread "Context configuration during webapp loading". The problem is that the static initialization and default configuration of logback is triggered by the first time something uses slf4j to get a Logger factory. At the very least, you must trigger this initialization yourself by the code you must use to get the LoggerContext to do customization in a *second* configuation. It seems to me logback ought to offer a way to inject code into this static initialization, so that you can customize the *first* configuration that runs. This would probably have to happen by a static method on some logback class involved in the initialization, and would require you to ensure your static code runs before any other static code but this would at least be an improvement IMO. Eric On 9/4/2012 1:01 PM, Eric Schwarzenbach wrote:
If I'm not mistaken this is more or less the same issue I was describing in the thread "Context configuration during webapp loading".
The problem is that the static initialization and default configuration of logback is triggered by the first time something uses slf4j to get a Logger factory org.slf4j.impl.StaticLoggerBinder init method. At the very least, you must trigger this initialization yourself by the code you must use to get the LoggerContext to do customization in a second *configuation*.
It seems to me logback ought to offer a way to inject code into this static initialization, so that you can customize this *first* configuration. This would probably have to happen by a static method on some logback class involved in the initialization, and would require you to ensure your static code runs before any other static code but this would at least be an improvement IMO.
Eric
On 9/4/2012 11:40 AM, Chris Pratt wrote:
I guess you could have your logback configuration file just specify the log file name as "preconfig.log", then have your code create a new appender with the right filename and replace the current file appender. You'd end up with a very small preconfig.log (which your code might even be able to rename to your new name before pointing logback at it) and the rest of the days logs would be in your newly configured file. (*Chris*)
On Tue, Sep 4, 2012 at 6:30 AM, Brett Walker <brett.walker@geometryit.com <mailto:brett.walker@geometryit.com>> wrote:
Hi Ceki,
When I first discovered logback about two years ago I saw this potential problem. I thought some sort of cyclic buffer as used by logback's status listener was a possible solution. The problem I saw was that filters, formatters and encoders were not set. Thus the logging event had to be stored in a 'raw' format (loggingEvent or something similar was sufficient) to be replayed back in an orderly manner, once the configuration of logback was complete. From memory, it was the orderly replay that I was yet to fully solve and the transition from a cyclic buffer to the effective logger as described in the configuration file.
I could see the scenario where application, upon startup, had not yet fully finished establishing it's environment yet third party libraries are emitting crucial log statements.
Some sort of buffer is needed. In most case it should not be needed.
It raises another question; "How to configure this temporary buffer?"
Brett Walker
On 04/09/2012, at 10:50 PM, "ceki" <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
> 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 >> >> > > > -- > Ceki > http://tinyurl.com/proLogback > _______________________________________________ > Logback-user mailing list > Logback-user@qos.ch <mailto:Logback-user@qos.ch> > http://mailman.qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list Logback-user@qos.ch <mailto:Logback-user@qos.ch> http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Very rapidly - usually within the first second. We are still in the initialization phase of our application. -----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
-- Ceki http://tinyurl.com/proLogback _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
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
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@qos.ch [mailto:logback-user-bounces@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@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
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
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@qos.ch [mailto:logback-user-bounces@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@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
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
participants (6)
-
Brett Walker -
ceki -
Chris Pratt -
Eric Schwarzenbach -
Ralph Goers -
Thorbjørn Ravn Andersen