On May 25, 2005, at 4:59 PM, Scott Deboy wrote:
This shouldn't be a factory. I don't want to have to manage the
instance, but I do want to reference the instance from anywhere
(this is assuming support for levels outside of TRACE, regardless
of if we still support the trace helper methods in loger).
The code-fragment was an example of how JCL could separate trace from
debug with the deployed log4j's. Its need disappears once there is a
public constructor on Level.
CustomLevelRegistry may make more sense, with statics for accessing
and registering levels (requiring syslog level support seems like a
pain - maybe we can have two 'register' methods, one that supports
syslog levels, one that doesn't but sets all custom levels to the
same syslog level.
CustomLevelRegistry.register(3000, "TRACE");
logger.log(CustomLevelRegistry.getLevel("TRACE"), "my message");
Regardless of how you obtain a custom level, it would be most good to
access static instances of them in a similar manner to accessing
Level.DEBUG etc. So in your code base, you could have
package com.example.corp.killerapp;
import org.apache.log4j.Level;
class CustomLevel {
private CustomLevel() {}
public static final Level TRACE = some construction mechanism;
public static final Level LETHAL = some construction mechanism;
public static final Level ULTRATRACE = some construction mechanism;
}
----
and in some other code
logger.log(CustomLevel.TRACE, "my message");
No need to have CustomLevelRegistry extend Level - it can live in
org.apache.log4j along with Level.
If someone wanted (for example, JCL) to use that approach now, it
would have to need to extend Level (or use reflection) since the
Level constructor is protected.
If we still feel like supporting trace helpers in logger, fine. We
do need to look at Level's toLevel method because it defaults to
DEBUG if it doesn't recognmize the level (this will need to change).
What we need to make sure is that we have a reasonable incremental
migration path from where we are to where we want to go. For example:
log4j 1.2.11 and earlier:
Level is non-final, constructor is protected. Custom levels require
extending Level or bypassing constructor access modifier. Category
exists. No mechanism for configuring custom thresholds.
log4j 1.2.12 (alternatively 1.3):
Level is non-final with new public constructor. Category exists.
Configuration should be modified to take at least an integer as an
alternative and possibly registration of new levels with
configurators. Existing protected constructor marked as deprecated.
log4j 1.3 or 2.0:
Category removed. Level is final.
Somewhere along there we might deprecate Level.toLevel() et al. I'd
like to avoid a global registry of Level's since different parts of
an application might have assigned different severities to their
"ULTRATRACE". Having configurations can accept integer severity
values (which is all that is needed to evaluate the thresholds) would
allow an app to be configured without needing to be aware of all the
levels used within its dependencies.
If we depend on integer severities to configure thresholds to custom
levels, then it may be good to provide a %severity format specifier
so you could actually see the integer values in log so you know how
to tweak them.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
