Project

General

Profile

Feature #1848

make logging settings controllable dynamically at runtime

Added by Greg Shah over 11 years ago. Updated 10 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Start date:
Due date:
% Done:

0%

Estimated time:
80.00 h
billable:
No
vendor_id:
GCD

Related issues

Related to Runtime Infrastructure - Bug #5703: rationalize, standardize and simplify the client-side log file name configuration Closed

History

#1 Updated by Greg Shah over 11 years ago

  • Target version set to Deployment and Management Improvements

#2 Updated by Greg Shah over 7 years ago

  • Target version changed from Deployment and Management Improvements to Deployment and Management Improvements

#3 Updated by Greg Shah over 4 years ago

The core objective is to allow an administrator to change the detailed logging levels at runtime, through the admin console.

As part of this work, these are some issues to address:

  • All logging must be done with the standard FWD logging helpers and configuration. Today there is some usage of log4j (mostly in persistence) and Apache commons (search on imports of org.apache.commons.logging).
  • Most places that log calculate the logging levels once (when the class loads). I think the easiest/cleanest approach:
    • Create a helper class which can be instantiated to hide the management and state of the logger.
    • Make this helper a listener where it registers for a callback when the logging level changes.
    • Expose simple APIs for common usage.
  • Create an admin UI for displaying/editing the logging levels and logging settings as they can be set in the directory.
    • Changes must be saved in the directory.
    • Fire the listener to change the state of existing loggers.

#4 Updated by Igor Skornyakov over 4 years ago

log4j exposes its loggers' settings via JMX, so there is no need for custom instrumentation. If we use log4j commons logging bridge than it will work for JCL as well.

#5 Updated by Galya B 10 months ago

  • Related to Bug #5703: rationalize, standardize and simplify the client-side log file name configuration added

#6 Updated by Galya B 10 months ago

A note: For dynamic levels to apply to all child packages and classes, all loggers should have fully qualified names (not simple names, check usage of class.getSimpleName()). Root logger (named "") level applies to all loggers, even those with simple names (when these are not set explicitly).

#7 Updated by Galya B 10 months ago

A note: With #5703 all levels can be changed dynamically. To not lose logs, when the level is lowered, isLoggable() should not be cached on the class or instance levels. Only admin menu is to be implemented.

#8 Updated by Greg Shah 10 months ago

A note: With #5703 all levels can be changed dynamically. To not lose logs, when the level is lowered, isLoggable() should not be cached on the class or instance levels. Only admin menu is to be implemented.

For performance reasons we often cache the result of isLoggable(). This should be maintained. We can easily do this by passing an optional listener to the LogHelper.getLogger() call which will be notified if the logging level changes for that logger.

#9 Updated by Galya B 10 months ago

Greg Shah wrote:

For performance reasons we often cache the result of isLoggable(). This should be maintained. We can easily do this by passing an optional listener to the LogHelper.getLogger() call which will be notified if the logging level changes for that logger.

isLoggable results are now cached in CentralLogger and invalidated when parent levels change. I tried to remove all class / object level cached results.

#10 Updated by Galya B 10 months ago

Client levels invalidation needs more work, check #5703-356 point 2.

Also available in: Atom PDF