tags:

views:

192

answers:

6

In the majority of cases I see Log instances declared as follows:

public static final Log LOG = LogFactory.getLog(MyClass.class);

I assume this means that the log configuration is loaded when the MyClass is loaded and is therefore set in stone until the MyClass is either reloaded or the JVM restarted?

So, if this assumption is correct what is the best way to ensure changes to the log configuration are picked up as (or as soon after) they happen?

+2  A: 

I assume that you are using commons-logging from the LogFactory class? As far as I know, none of the usual logging implementations (Log4J, java.util.logging) allow you to reload a configuration file in a running application (regardless of whether the actuall Loggers are declared as static variables). (EDIT: Peter's answer below proves that I was wrong about this in the case of Log4J)

However, they do allow for the dynamic changing of logging levels (e.g. via an MBean). These level-changes will be picked up by any Logger (including those declared as static variables). If you use java.util.logging you get the MBean for free in the JConsole.

Is it just the changing of levels you care about, or do you wish to provide completely different logging configurations (e.g. files, logger definitions) on the fly?

oxbow_lakes
Yes, it'd just be the logging levels that I'd want to change so I'll take a closer look at the MBean route.
Nick Holt
It's actually extremely easy to add a Log4J / `j.u.l` "bridge" which means that you can use the `j.u.l` MBeans to manage your Log4J loggers
oxbow_lakes
Log4j will reload your config file whenever it changes, if you so desire. see my answer.
Peter Recore
Thanks Peter - I wasn't aware of that
oxbow_lakes
+2  A: 

I guess this depends on the underlying implementation, as pointed out by oxbow_lanes. Generally, it might be difficult to reconfigure your logging subsystem if you are relying on config files that are available via the classpath. To get around this limitation, we do all our config programmatically, and do not rely on only static config files. But I don't know whether your implementation support programmatic reconfiguration.

omerkudat
+2  A: 

No, the log configuration is loaded typically when the logging implementation classes are initialized. When your class is (re)loaded, all that happens is that the logging API is called to get a logger (which may or may not be present in any configuration) and stored as a class variable.

To reload your logging configuration, then you typically would have to get the logging implementation to reload.

Vinay Sajip
+1  A: 

Actually, if you are using "java.util.logging" logging directly, then you CAN reload the logger configurations on the fly. There are two methods on the LogManager class for doing this:

public void readConfiguration() 
    throws IOException, SecurityException

This reloads the default logging properties and reinitializes the logging configuration.

public void readConfiguration(InputStream ins)
    throws IOException, SecurityException

This loads the logging properties from a stream (in Property file format) and reinitializes the logging configuration.

See the LogManager javadoc.

Stephen C
+2  A: 

Depends on the backend.

Logback has a very niftly feature where the reload can be triggered by JMX, i.e. in jvisualvm or jconsole.

Thorbjørn Ravn Andersen
Recent version of logback added an auto-scan feature which is even cooler. http://logback.qos.ch/manual/configuration.html#autoScan
Ceki
+1  A: 

Log4j can reload your config file whenever it changes.

see the faq here

Is there a way to get log4j to automatically reload a configuration file if it changes?

Yes. Both the DOMConfigurator and the PropertyConfigurator support automatic reloading through the configureAndWatch method. See the API documentation for more details.

Because the configureAndWatch launches a separate wathdog thread, and because there is no way to stop this thread in log4j 1.2, the configureAndWatch method is unsafe for use in J2EE envrironments where applications are recycled.

Peter Recore