[
https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874415#action_12874415
]
Curt Arnold commented on LOG4J2-41:
-----------------------------------
Both java.util.logging and log4j 1.2 support user defined levels using
extensions of their level class. While often the capability is misused to
imply something about the audience (like an audit level) that would be better
done using the logger name, there will be code that depends on the capability.
In addition, some logging frameworks may not have the concept of level or use
an integer level.
Both log4j and java.util.logging's Level have integer values associated with
the predefined levels. The assigned values are not compatible, all of
java.util.logging levels other than OFF have values less than log4j's DEBUG.
The current take in my log4j 2.0 branch is to allow mapping of existing API
level values to a "generic" int value for quick threshold testing but also
allow filtering based on the specific level passed in case you want to
distinguish between jul's INFO and log4j's INFO.
If you can't map to the generic level int space, then you can return a generic
int of Integer.MAX_VALUE guaranteeing passage through the int threshold and
then filter on the specific level object.
The current code requires passing an implementation of
org.apache.logging.core.Level which would likely require managing a set of
mapping objects as you would want to avoid unnecessary object creation prior to
the threshold evaluation. While that it likely tolerable as long as the
predefined levels are used, a naive implementation would likely exhaust memory
if the user called with random int values.
While this would not be exposed at the client API level, I'm thinking that the
backend may need to take an Object level paired with a LevelFormatter class
that handles conversion to the generic int space. The bridge between a
specific API to the backend would be responsible to making sure they were
matched.
> Extensible Log Level
> --------------------
>
> Key: LOG4J2-41
> URL: https://issues.apache.org/jira/browse/LOG4J2-41
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Reporter: Ralph Goers
>
> It is desirable to have the Level be an enum. However, it is also desirable
> to let users add new log levels. These goals are in opposition to each other
> since enum classes are final. In addition, adding new levels implies adding
> new methods to the Logger interface (or some counterpart to it). This would
> be unworkable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
