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

[Rusty Wright]

This doesn't really answer your question except indirectly, but I've recently started drinking the maven kool-aid and it can help in this situation.

I was doing something just like what you're doing except I was using the host name to do the switching.

With maven you can have different profiles, and you specify which one to use when you build; for example,

  mvn -Pdev ...
  mvn -Ptest ...

In your maven config file, pom.xml, you can specify properties, which can have different values for each profile.  For example, you could have a property called logFile.

Then in your source tree you put your various configuration files for your app in a directory called resources and tell maven to filter those files before it puts them in the war file (or jar, or whatever) and it replaces property placeholders when it does the filtering.  So you could have your logback.xml file in the resources folder, and in it have, for example

  <file>${logFile}</file>

Then when maven compiles everything and builds the war file it will replace that ${logFile} with the value you specified in your pom.xml for whatever profile you built with.

Then you only need one logback.xml file and it gets properly massaged when you do your build.


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