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

[Eric Schwarzenbach]

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 at geometryit.com <mailto:brett.walker at 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 at qos.ch
>     <mailto:ceki at 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 at qos.ch <mailto:Logback-user at qos.ch>
>     > http://mailman.qos.ch/mailman/listinfo/logback-user
>     _______________________________________________
>     Logback-user mailing list
>     Logback-user at qos.ch <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20120904/f3664dcf/attachment-0001.html>