Changing loglevel at runtime (systemwide)

[Detering Dirk <de...@iskv.de>]

Hello all,

I subscribed to this list to get some help regarding 
a problem with conditional level switching we encountered 
in our development team.

Let me first explain what we do and why.

Background:

Application:  A code generator, doing two steps: 
Model validation and code generation for each class in 
the model (more or less). The generator is developed in 
our team but used in many other application development 
teams.

Problem:
The validation may be incomplete, causing the generator 
to throw runtime exceptions at unexpected locations during 
the generation step.
In this case, the stack trace isn't very helpful, as it 
documents somehow _where_ the problem occurred, but not 
clearly _why_  (means: which model element caused the 
problem). This is partly due to Velocity.

Current solution:
The time consuming solution is to reconfigure the log settings to
get DEBUG infos from different generator classes during runtime,
and restart the whole generation.

   Drawback:  
   * A generator developer has to be involved to analyse
     the stack and do the right debug configurations
   * The complete generator run has to be repeated
   * When switching a Logger to DEBUG, it _always_ 
     logs what it does, not only for the problematic part/element 
     of the input model. So the output has to be filtered to 
     separate the relevant information from noise.

Perhaps better concept:
Our intention was to catch the thrown exceptions at the location
where the model is iterated and the generation triggered for each 
element, and to retry the generation after setting the whole system 
into DEBUG mode - and setting it back to its former state after 
catching the exception again(!)

   Advantage:
   * We would get a verbose track of what the system does, 
     but only with the critical model element, not with all 
     others.
   * The debug info would automatically be created during the 
     first run by the app. developer. So no need to completely
     rerun, no need to configure, no need to involve our dev.
     team at this stage.
     

Here's our log4j problem why I post now:

As the basic configuration is just complex, involving many
loggers and appenders, we can't only set one or two logger 
into debug mode. Settings at some upper level in the 
hierarchy don't help, as some loggers much deeper are configured
explicitly and keep their own setting.

Reconfiguring with another property set would presumably
cause rolling file appenders to create a new generation
after restoring the configuration (?).

So we tried to write a RepositorySelector do retrieve another
(much simpler) hierarchy in case the system goes into debug.

But this does not work either, as the Loggers are instanciated
and kept in static variables of classes (as recommended)
which are put into caches _before_ the system switches to DEBUG, 
i.e.: The second hierarchy is mostly never queried, each instance
knows its logger.

So, what would be the right way to achieve a systemwide
switch to debug level and a reset to normal configuration
afterwards?

Any hints are welcome

KR
Dirk Detering

--
ISKV 
Paul-Klinger-Straße 15
45127 Essen
Telefon  +49-(0)-201-1094-0
Fax      +49-(0)-201-1094-444 
< http://www.iskv.de/>

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

Re: Changing loglevel at runtime (systemwide)

[Curt Arnold <ca...@apache.org>]

Manipulating the repository threshold might accomplish what you are  
trying to do.  Every event is evaluated relative to the repository  
threshold before being evaluated against logger and appender  
thresholds.  If you set the repository threshold to "info" but set  
the loggers and appenders to "debug", only "info" and higher messages  
will be processed until the threshold is lowered to "debug".

The repository threshold can be specified in a configuration file:

<log4j:configuration threshold="info"...>

or

log4j.threshold=info

or by code:

logger.getLoggerRepository().setThreshold(Level.DEBUG);



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

Re: Changing loglevel at runtime (systemwide)

[James Stauffer <st...@gmail.com>]

Would it work to have two output files(or sets of files) -- one at
normal level and one at debug level?  Then if you don't need the debug
output just delete the debug logs.

On 1/25/07, Detering Dirk <de...@iskv.de> wrote:
> Hello all,
>
> I subscribed to this list to get some help regarding
> a problem with conditional level switching we encountered
> in our development team.
>
> Let me first explain what we do and why.
>
> Background:
>
> Application:  A code generator, doing two steps:
> Model validation and code generation for each class in
> the model (more or less). The generator is developed in
> our team but used in many other application development
> teams.
>
> Problem:
> The validation may be incomplete, causing the generator
> to throw runtime exceptions at unexpected locations during
> the generation step.
> In this case, the stack trace isn't very helpful, as it
> documents somehow _where_ the problem occurred, but not
> clearly _why_  (means: which model element caused the
> problem). This is partly due to Velocity.
>
> Current solution:
> The time consuming solution is to reconfigure the log settings to
> get DEBUG infos from different generator classes during runtime,
> and restart the whole generation.
>
>    Drawback:
>    * A generator developer has to be involved to analyse
>      the stack and do the right debug configurations
>    * The complete generator run has to be repeated
>    * When switching a Logger to DEBUG, it _always_
>      logs what it does, not only for the problematic part/element
>      of the input model. So the output has to be filtered to
>      separate the relevant information from noise.
>
> Perhaps better concept:
> Our intention was to catch the thrown exceptions at the location
> where the model is iterated and the generation triggered for each
> element, and to retry the generation after setting the whole system
> into DEBUG mode - and setting it back to its former state after
> catching the exception again(!)
>
>    Advantage:
>    * We would get a verbose track of what the system does,
>      but only with the critical model element, not with all
>      others.
>    * The debug info would automatically be created during the
>      first run by the app. developer. So no need to completely
>      rerun, no need to configure, no need to involve our dev.
>      team at this stage.
>
>
> Here's our log4j problem why I post now:
>
> As the basic configuration is just complex, involving many
> loggers and appenders, we can't only set one or two logger
> into debug mode. Settings at some upper level in the
> hierarchy don't help, as some loggers much deeper are configured
> explicitly and keep their own setting.
>
> Reconfiguring with another property set would presumably
> cause rolling file appenders to create a new generation
> after restoring the configuration (?).
>
> So we tried to write a RepositorySelector do retrieve another
> (much simpler) hierarchy in case the system goes into debug.
>
> But this does not work either, as the Loggers are instanciated
> and kept in static variables of classes (as recommended)
> which are put into caches _before_ the system switches to DEBUG,
> i.e.: The second hierarchy is mostly never queried, each instance
> knows its logger.
>
> So, what would be the right way to achieve a systemwide
> switch to debug level and a reset to normal configuration
> afterwards?
>
> Any hints are welcome
>
> KR
> Dirk Detering
>
> --
> ISKV
> Paul-Klinger-Straße 15
> 45127 Essen
> Telefon  +49-(0)-201-1094-0
> Fax      +49-(0)-201-1094-444
> < http://www.iskv.de/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>


-- 
James Stauffer        http://www.geocities.com/stauffer_james/
Are you good? Take the test at http://www.livingwaters.com/good/

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org