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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
James Stauffer http://www.geocities.com/stauffer_james/
Are you good? Take the test at http://www.livingwaters.com/good/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
