[logback-user] question about start-up process and disabling auto-configuration

[Rob Ross]

Let me share my use-case, and how I'm using logback, and maybe you can  
suggest a better way of using it.

In this case I'm writing a Swing desktop application that will talk to  
something on the back-end, either a database directly, or an app server.

I have a properties file that among other things, has a flag for  
controlling the run-time environment, either in Dev, Test, or  
Production mode.

It's a single switch that causes various classes and database  
connections to be used depending on the value. E.g., in Test mode I  
connect to the Test database, in Prod mode I connect to the Production  
database. I have an ant build script that has discrete targets for  
making a production build, or  a test build, etc. One of the tasks is  
to set the switch to the right value (Dev/Test/Prod).

I  have set up two logback configuration files, a logback.xml, and a  
logback-test.xml. The test version is set up for more low-level  
logging among other things.

I have a LoggingUtils class that queries the environment property and  
then reads in either the logback.xml or logback-test.xml, and calls  
doConfigure() with the appropriate config file.

I have both config files in the classpath. Perhaps I should not do  
this, but it makes it easier to keep them in the same resource  
directory when I have to edit it. Usually I want to add common  
functionality to both at the same time.

But what happens is when the app starts up, it always loads the  
logback-test.xml file, which is set with "debug = true" attribute. So  
even when I'm running the production version of the app, first the  
test config file is auto-loaded, then I manually load the production  
config file and call doConfigure(). But since the test file is loaded  
automatically, it prints out the config information, since it's using  
the debug=true option.

So, I'm probably not using this correctly, but hopefully now that you  
understand what I'm trying to do you can suggest a better way of using  
the tool.

Thanks,

Rob

So if there was some way to
On Dec 3, 2008, at 1:40 PM, Ceki Gulcu wrote:

> Hello Rob,
>
> There should be no status messages printed during automatic (default)
> configuration, unless errors occur.
>
> Are you saying that automatic configuration using logback.xml fails  
> because of
> missing variables which you fill in when you call doConfigure()?
>
> If you know how to find the configuration file, why don't you rename
> "logback.xml" to something else so that it does not get picked up?
>
> BTW, there is no way to disable automatic configuration. However,  
> you can set a
> system property to specify a different configuration file URL.
> For more details, search for "Specifying the location of the default
> configuration file as a system property" in http://logback.qos.ch/manual/joran.html
>
>
> Rob Ross wrote:
>> Is there a way to disable the auto-configuration at startup? One of
>> the first things my app does is locate the right configuration file
>> (logback.xml) to use for the current environment and calls
>> doConfigure().
>>
>> But, when the app first starts up, it automatically configures  
>> Logback
>> and prints out the debug information to System.out. Since I
>> immediately re-configure logback, this seems like a waste and the
>> status messages are also extraneous.
>>
>> Is there a way to suppress the auto-configuration at startup so I can
>> handle it myself? Or at least not print out those auto-configuration
>> messages on System.out?
>>
>> Thanks!
>>
>> Rob
>
> -- 
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework  
> for Java.
> http://logback.qos.ch
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user