[logback-user] Programmatic logback Configuration

Chad La Joie chad.lajoie at switch.ch
Wed Nov 7 09:03:39 CET 2007


Sigh...  after looking at the logging config for like the 50th time I 
found a typo in one of the package names.

One thing I did notice, but didn't expect, was the following.

Assume a file appender called FILE.  The following config

<logger name="some.package">
    <level value="DEBUG" />
    <appender-ref ref="FILE" />
</logger>

<root>
    <level value="WARN" />
    <appender-ref ref="FILE />
</root>

causes messages to some.package to be logged twice.  I can certainly 
understand why, but it would be preferable if logback detected that it 
already logged a message to a given appender and skip it if it happens 
to appear more than once.  This way people can take advantage of the 
inheritance when they need/want to but can also explicitly declare the 
appender, for the logger, without worry of duplicate messages.

Ceki Gulcu wrote:
> Chad,
> 
> Your code looks good, although the loggerContext.start() call seems 
> superfluous
> to me.
> 
> Declaration of new loggers should be picker up. Is it possible that the 
> problems lies with the contents of the UEF file? I mean what happens 
> when you replace the contents of DLF with the contents of UEF?
> 
> Could you provide the contents of both files?
> 
> Chad La Joie wrote:
>> I apologize for being pushy.  Are there others on this list?  Should I 
>> be using a different list?
>>
>> Chad La Joie wrote:
>>> I have an application that ships with two logging configuration files;
>>> a default logback.xml file (DLF) included in the application JAR and 
>>> a user-editable file (UEF) installed on the filesystem with other 
>>> application configuration files.  The DLF is used when the 
>>> application is starting but before the code to read in the UEF is 
>>> executed.
>>>
>>> My current code for reading in the UEF looks like this:
>>>
>>> LoggerContext loggerContext = (LoggerContext) 
>>> LoggerFactory.getILoggerFactory();
>>>
>>> loggerContext.shutdownAndReset();
>>>
>>> JoranConfigurator configurator = new JoranConfigurator();
>>>
>>> configurator.setContext(loggerContext);
>>>
>>> configurator.doConfigure(configuration.getInputStream());
>>>
>>> loggerContext.start();
>>>
>>> The behavior I'm seeing though is note quite what I expected.  Assume 
>>> the DLF contains a console appender and a logger definition for 
>>> package "foo".  The behavior I see when the UEF is loaded is:
>>>
>>>   - Changes to the logger FOO (e.g. changes in the logging level, 
>>> addition/removal of appenders, etc.) are picked up and become active.
>>>
>>>   - Declaration of new appenders are picked up and become active 
>>> (e.g. if a new file appender is defined I can see it creating the new 
>>> log file).
>>>
>>>   - Declaration of new loggers are *not* picked up.  If, for example, 
>>> a logger "bar" is defined and given the same console appender as 
>>> "foo" no output from "bar" is sent to the console.
>>>
>>> Is this expected behavior?  Is my code wrong (I've tried the same 
>>> code without the start() or shutdownAndReset() method calls)?
>>>
>>> Any help would be appreciated.
>>>
>>
> 

-- 
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad.lajoie at switch.ch, http://www.switch.ch



More information about the Logback-user mailing list