cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: [c3] Reconfigure log4j settings via JMX.
Date Thu, 02 Apr 2009 10:04:29 GMT
Dariusz Łuksza wrote:
> Hi,
> I'm currently looking over cocoon-spring-configurator sources for a
> hints how to implement reconfiguration via JMX and there are my
> reflections:
> In current solution there is Log4JConfigurator class that handles
> configuration of log4j and by calling:
> setResource(resource);
> afterPropertiesSet();
> we could change logging properties.
> (May it cause any errors or exceptions when it would be performed on a
> fully started system ?)
> IMHO current solution is useless if it would be accessed directly by
> JMX because as an argument must be passed path to local file with new
> setting. Therefor there should be one more layer that would be giving
> possibility of review all current settings and possibility of change
> one (or more) of them. So I'm thinking of new class eg.
> JmxLog4JConfigurator that would warps around Log4JConfigurator. In
> this new class we would have tree representation of xml configuration
> file that gives us simple way of reconfiguration. After all changes
> there should be called save() or commit() method that would collect
> all settings and pass them via setResource to Log4JConfigurator and
> call afterPropertiesSet() to perform changes.
> But there is a small problem, because currently there isn't any way of
> obtaining actual configuration, so there must be added one getter
> method into Log4JConfigurator that would return all actual settings.
> It is my idea of solving "review and reconfigure log4j settings via
> JMX" ... is it correct ? ;)

Thanks for your analysis. I'm quite confident that we only have to
change the Log4JConfigurator a little to get what we want. But let's try
to be more specific about that. I think that we have to distinguish
between two use cases:

 1. Changing the log level of one particular log target (usually the
    class name)

 2. Reloading the complete configuration file

The first one is useful when you want to trace unexpected behavior of a
production system. This is just temporary and doesn't need to be
persisted. We could even think about letting those changes expire after
some time provided by the user or use a default value (e.g. one hour).

If you want to change your logging file permanently or more
substantially (e.g. you want to add an appender), you have to edit the
logging file. I'm not sure how this should be done in detail, but I was
thinking about changing the configuration file (of course in this case
the file mustn't be part of the WAR file but has to be put separately
into the filesystem) and then you push a 'reload button' in the JMX
console. But maybe there is some more elegant way to do this.

It would be nice to validate the file before it gets applied so that
log4j doesn't get into an indefinite state

By the way, see that I
haven't tried but from looking into the code it goes into the right


Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

View raw message