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/10/30 19:03:19 UTC

[jira] Commented: (LOG4J2-41) Extensible Log Level

    [ 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