RE: Changing loglevel at runtime (systemwide)
> 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". When I understood the threshold correctly, this would OTOH for debugging of a single class (=logger) require to lower the threshold to "debug" and reconfigure all other loggers to "not debug". So: this setup would make it impossible to set some loggers to "error" or "fatal" by default, as every logger *has* to be configured for "debug" to make the scenario work. Any other configuration on user (app.-dev.) site would destroy this functionality. Am I right? > > The repository threshold can be specified in a configuration file: > > > > or > > log4j.threshold=info > > or by code: > > logger.getLoggerRepository().setThreshold(Level.DEBUG); > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > *** Die Information in dieser email ist vertraulich und ist ausschliesslich fuer den/die benannten Adressaten bestimmt. Ein Zugriff auf diese email durch andere Personen als den/die benannten Adressaten ist nicht gestattet. Sollten Sie nicht der benannte Adressat sein, loeschen Sie bitte diese email. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing loglevel at runtime (systemwide)
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: or log4j.threshold=info or by code: logger.getLoggerRepository().setThreshold(Level.DEBUG); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing loglevel at runtime (systemwide)
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 Staufferhttp://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]
Changing loglevel at runtime (systemwide)
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]
