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

[Ceki Gulcu]

I would suggest having 3 files, say logback-dev.xml, lb-test.xml, and 
logback-production.xml, all located in the same folder, respectively for your 
dev, test, and production environments. You would then have your ant targets 
rename and copy the appropriate file as logback.xml during the build. Since you 
already have separate targets for each environments, it should be an easy 
addition. You could even use macros to reduce duplication.

Rob Ross wrote:
> 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
> 
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user
> 

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch