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@qos.ch http://qos.ch/mailman/listinfo/logback-user

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@qos.ch http://qos.ch/mailman/listinfo/logback-user

_______________________________________________ Logback-user mailing list Logback-user@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