[c3] Reconfigure log4j settings via JMX.

[Dariusz Łuksza <da...@gmail.com>]

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 ? ;)

Best,
-- 
Blog: http://luksza.org
LinkedIn: http://www.linkedin.com/in/dariuszluksza

Re: [c3] Reconfigure log4j settings via JMX.

[Dariusz Łuksza <da...@gmail.com>]

On Thu, Apr 2, 2009 at 12:04 PM, Reinhard Pötz <re...@apache.org> wrote:
> 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).

Idea of "temporary changed log level" is very nice, I like it ;)

> 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.

IMHO this feature would be great for project kick of but I have idea
how to extend it in next versions.

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

Yes, validation is necessary.

> By the way, see http://code.google.com/p/logging-jmx-service/ that I
> haven't tried but from looking into the code it goes into the right
> direction.

It is very simple solution but I think I found there way how to get
logger settings without changing Log4JConfigurator ...  actually we
can do every thing without Log4JConfigurator, but I'm, not sure if it
is our way to do it. Going back to the heart of the matter using
LogManager class from log4j I think we can obtain actual configuration
of log4j, add logging configuration for single class/package and
change these configurations.

> WDYT?

I think that this task wouldn't be so hard as I think so ;)

-- 
Best regards
Blog: http://luksza.org
LinkedIn: http://www.linkedin.com/in/dariuszluksza

Re: [c3] Reconfigure log4j settings via JMX.

[Reinhard Pötz <re...@apache.org>]

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 http://code.google.com/p/logging-jmx-service/ that I
haven't tried but from looking into the code it goes into the right
direction.

WDYT?

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________