[logback-user] Context configuration during webapp loading

Eric Schwarzenbach subscriber at blackbrook.org
Thu Aug 23 21:59:14 CEST 2012


The way that the logback FAQ example for shared configuration for 
multiple JEE apps is written, it WILL create this superflous log file, 
application-name_IS_UNDEFINED.log (unless there is some system specific 
behavior involved in creating an empty file when the stream is opened).

The way logback's slfj static logger binding mechanism is written it 
seems to be necessary to let it configure itself once before you can get 
a hold of the LoggerContext to configure it. It would be nice if there 
were a way to inject configuration behavior into StaticLoggerBinder so 
that it would use it, and not force you to do a second configuration the 
way both this example and the manual's "Invoking JoranConfigurator 
directly" example does it.

This situation seems to have JMX implications too. In my case, I am 
setting my context name using a property the same way I am dynamically 
setting the log file names. When I look at that using the Java 
Management Console, I see a /application-nameIS_UNDEFINEDLogbackContext 
but no entry with my revised context name after the re-config.

My workaround (for both the spurious log file and the context name) is 
to set application-name as a system property, instead of doing what the 
example code does. Perhaps the example should be changed to do that, 
though it would be nicer to be able to pass a property specifically to 
logback instead of sticking it in the global system property space.

Cheers,

Eric

On 8/22/2012 3:38 PM, Eric Schwarzenbach wrote:
> I realized I needed to move my ServletContextListener above the Spring 
> ContextLoaderListener in my web.xml. However it is still creating a 
> application-name_IS_UNDEFINED.log, though an empty (0 byte) one.
>
> Putting a breakpoint on the ContextLoaderListener**doConfigure 
> methods, I see it is getting called as a result of the line
>
> LoggerContext context = (LoggerContext) 
> LoggerFactory.getILoggerFactory();
>
> (from the manual's example) via org.slf4j.impl.StaticLoggerBinder init 
> method  (from the logback-classic.jar).
>
> Any suggestions how I can avoid that? Is there a better way to get the 
> LoggerContext?
>
> Eric
>
> On 8/22/2012 2:53 PM, Eric Schwarzenbach wrote:
>> I'm trying to use variable substitution for my log file names, using 
>> the webapp / context name. (My use case is not literally a shared 
>> configuration, but two webapps deployed using copies of the same war 
>> with different names...so they each have their own logback.xml, 
>> though they are identical). I'm using the example on 
>> http://logback.qos.ch/faq.html#sharedConfiguration as my basis, and 
>> while it is working, my webapp ends up creating two log files.
>>
>> First it creates one called application-name_IS_UNDEFINED.log with 
>> some of the first messages logged during startup, and then foo.log 
>> (where foo is the app name) with all subsequent messages. So it seems 
>> to me that the contextInitialized method of ServletContextListener 
>> isn't early enough, and that the default logback config is 
>> initializing earlier. This is using Tomcat 7, and Java 7.
>>
>> How can I either hook into the earlier initialization or replace it? 
>> Where does that initialization happen? Is that static code?
>>
>> Thanks,
>>
>> Eric
>>
>> _______________________________________________
>> Logback-user mailing list
>> 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/20120823/817c2b9b/attachment.html>


More information about the Logback-user mailing list