[
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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
