You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Ralph Goers (JIRA)" <ji...@apache.org> on 2010/05/31 22:25:40 UTC
[jira] Created: (LOG4J2-41) Extensible Log Level
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-41) Extensible Log Level
Posted by "Curt Arnold (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893924#action_12893924 ]
Curt Arnold commented on LOG4J2-41:
-----------------------------------
I agree that most urges to use extensible levels are misguided attempts to use levels for something other than the significance of the message. Every now and again someone will will say they are having problems while trying to implement an AUDIT level when that is not a significance but an audience and is the appropriate domain of the logger path or an SLF4J marker. Even for "audit" events, there would be a range of significance ($100: DEBUG, $10000 INFO, $1,000,000,000,000 FATAL) and by using the level for AUDIT, you lose any mechanism for communicating the significance.
However, that it can be misused does not invalidate proper use and they are a few legitimate uses (mapping the use of an in-house logging framework with more levels, for example). Unless the core supports some mechanism to extend the level space, then it would not be possible to provide a plug compatible experience for those log4j and java.util.Logging users who used level extension in a proper manner.
If it becomes obvious that there is a huge cost in implementing extensible levels and the proportion of users affected by the elimination of the feature is small, then it could be abandoned. However, putting in the JIRA was an attempt to keep in the mix of design features that could be desirable so that something that might be a migration block isn't overlooked in the design process.
> 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-41) Extensible Log Level
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893952#action_12893952 ]
Ralph Goers commented on LOG4J2-41:
-----------------------------------
I'm not suggesting that this issue be closed at this point, just that it changes my perspective on the value of fixing it. There are distinct advantages in using Enums over static ints. The other thing to consider is that every level has a corresponding set of methods on the Logger interface. These won't exist for custom levels unless a custom Logger interface is used. It would take a bit of convincing for me to understand how this would be a good thing.
> 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-41) Extensible Log Level
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926611#action_12926611 ]
Ralph Goers commented on LOG4J2-41:
-----------------------------------
After more work and thought I am more inclined to believe that this is not something we should do. Using markers in combination with the existing set of log levels should provide all the flexibility anyone could want.
I could easily picture the mapping mechanism you describe for in-house logging frameworks where there is a routine that accepts the JUL Level (extended) and returns an object containing the Marker and Level to use. This would easily allow an adapter mapping the in-house API to Logj2. Of course, Log4j2 is designed so that anyone can plug in an alternate implementation behind the API.
> 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-41) Extensible Log Level
Posted by "Curt Arnold (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-41) Extensible Log Level
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893616#action_12893616 ]
Ralph Goers commented on LOG4J2-41:
-----------------------------------
A brief discussion just took place on the Logback mailing list on this topic. A user wanted custom log levels. When asked why it was so they could split the existing levels into finer pieces. It was pointed out that this is what markers are for and serve the purpose well. Since Markers have been added to my implementation of log4j 2.0 I am going to conclude that this feature (exensible log levels) is related to LOG4J2-16, if not a duplicate of it.
IMO this approach makes the most sense since the Level can continue to be an Enum while still allowing the individual levels to be decorated.
> 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Issue Comment Edited: (LOG4J2-41) Extensible Log Level
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926611#action_12926611 ]
Ralph Goers edited comment on LOG4J2-41 at 10/30/10 1:07 PM:
-------------------------------------------------------------
After more work and thought I am more inclined to believe that this is not something we should do. Using markers in combination with the existing set of log levels should provide all the flexibility anyone could want.
I could easily picture the mapping mechanism you describe for in-house logging frameworks where there is a routine that accepts the JUL Level (extended) and returns an object containing the Marker and Level to use. This would easily allow an adapter mapping the in-house API to Logj2. Of course, Log4j2 is designed so that anyone can plug in an alternate implementation behind the API so going the other way shouldn't be a problem.
was (Author: ralph.goers@dslextreme.com):
After more work and thought I am more inclined to believe that this is not something we should do. Using markers in combination with the existing set of log levels should provide all the flexibility anyone could want.
I could easily picture the mapping mechanism you describe for in-house logging frameworks where there is a routine that accepts the JUL Level (extended) and returns an object containing the Marker and Level to use. This would easily allow an adapter mapping the in-house API to Logj2. Of course, Log4j2 is designed so that anyone can plug in an alternate implementation behind the API.
> 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org