<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Sorry I accidentally left half of
another sentence in there which garbled things. Here is my last
post again without the garbling:<br>
<br>
If I'm not mistaken this is more or less the same issue I was
describing in the thread "Context configuration during webapp
loading".<br>
<br>
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.<br>
<br>
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.<br>
<br>
Eric<br>
<br>
On 9/4/2012 1:01 PM, Eric Schwarzenbach wrote:<br>
</div>
<blockquote cite="mid:504633D6.8080109@blackbrook.org" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">If I'm not mistaken this is more or
less the same issue I was describing in the thread "Context
configuration during webapp loading".<br>
<br>
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*.<br>
<br>
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.<br>
<br>
Eric<br>
<br>
On 9/4/2012 11:40 AM, Chris Pratt wrote:<br>
</div>
<blockquote
cite="mid:CAALdY0wX8d1PgWOrAMOc9CyUUmd4DQY1ERAdZWTxhyqKON_fYw@mail.gmail.com"
type="cite">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.
<div> (*Chris*)<br>
<br>
<div class="gmail_quote">On Tue, Sep 4, 2012 at 6:30 AM, Brett
Walker <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:brett.walker@geometryit.com"
target="_blank">brett.walker@geometryit.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ceki,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Some sort of buffer is needed. In most case it should not
be needed.<br>
<br>
It raises another question; "How to configure this
temporary buffer?"<br>
<span class="HOEnZb"><font color="#888888"><br>
Brett Walker<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
On 04/09/2012, at 10:50 PM, "ceki" <<a
moz-do-not-send="true" href="mailto:ceki@qos.ch">ceki@qos.ch</a>>
wrote:<br>
<br>
> How much time are we talking about between
logback initialization and<br>
> the time where the value of the property is
known?<br>
><br>
> On 04.09.2012 14:38, Thorbjørn Ravn Andersen
wrote:<br>
>> We have done plain old “just log to a new
file for the duration of the<br>
>> program – delete old logs daily” for several
years now and found it<br>
>> works well for us.<br>
>><br>
>> Now I have a rather tricky situation where
part of the file name to be<br>
>> used by (a subclass of) FileAppender needs to
be supplied by my code,<br>
>> but the initialization phase of the
application contains log statements<br>
>> triggering the initialization of logback
_/before/_ the property<br>
>> referred to by the FileAppender name string
is set causing the log file<br>
>> to have an incorrect name.<br>
>><br>
>> Basically what I have found to be the
behavior I want is for logback to<br>
>> await opening the file and write data before
I say it can.<br>
>><br>
>> Question is how I can do this within the
limits of logback. Can I tell<br>
>> logback to just buffer events in memory (this
will only be for a few<br>
>> seconds, and memory will most likely not be
an issue) – some kind of<br>
>> valve? Can I tell FileAppender to write to a
temporary file and rename<br>
>> it whenever the name is ready (perhaps using
some of the Policies from<br>
>> RollingFileAppender)?<br>
>><br>
>> Any suggestions on how to handle this?<br>
>><br>
>> Note: As we restart our application daily we
do not need<br>
>> RollingFileAppender for our general logging –
instead we have subclassed<br>
>> FileAppender to remove “older than X days”
files from the target<br>
>> folder. This has proven to work very well
for our scenario.<br>
>><br>
>> Thanks<br>
>><br>
>> /Thorbjørn<br>
>><br>
>><br>
><br>
><br>
> --<br>
> Ceki<br>
> <a moz-do-not-send="true"
href="http://tinyurl.com/proLogback" target="_blank">http://tinyurl.com/proLogback</a><br>
> _______________________________________________<br>
> Logback-user mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Logback-user@qos.ch">Logback-user@qos.ch</a><br>
> <a moz-do-not-send="true"
href="http://mailman.qos.ch/mailman/listinfo/logback-user"
target="_blank">http://mailman.qos.ch/mailman/listinfo/logback-user</a><br>
_______________________________________________<br>
Logback-user mailing list<br>
<a moz-do-not-send="true"
href="mailto:Logback-user@qos.ch">Logback-user@qos.ch</a><br>
<a moz-do-not-send="true"
href="http://mailman.qos.ch/mailman/listinfo/logback-user"
target="_blank">http://mailman.qos.ch/mailman/listinfo/logback-user</a></div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Logback-user mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Logback-user@qos.ch">Logback-user@qos.ch</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mailman.qos.ch/mailman/listinfo/logback-user">http://mailman.qos.ch/mailman/listinfo/logback-user</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Logback-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Logback-user@qos.ch">Logback-user@qos.ch</a>
<a class="moz-txt-link-freetext" href="http://mailman.qos.ch/mailman/listinfo/logback-user">http://mailman.qos.ch/mailman/listinfo/logback-user</a></pre>
</blockquote>
<br>
</body>
</html>