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 > [email protected] > http://qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
