[
https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831753#comment-13831753
]
Nick Williams commented on LOG4J2-41:
-------------------------------------
So I hate to reopen old wounds, but I'm going to give a little bit of a gripe
here. I'm in the review stage for my book, and I just read the following
sentences in my logging chapter:
{quote}Because {{Level}} is an enum, it cannot be extended. These are the only
levels you can use in Log4j 2.{quote}
This made me cringe, and reminded me of this issue. This keeps coming up in the
mailing list, and for good reason. The logging levels we have defined work well
for most developers. But the {{Level}} enum is *not* an _exhaustive_ list of
every level every developer will ever need. Yes, that's a *good* thing—an enum
with dozens of levels in it (and a {{Logger}} API to match) would be useless.
However, the use of an enum makes it _very hard_ for developers to adapt Log4j
to suit their needs. I'm going to use a hypothetical {{CONFIG}} level, which
logically falls somewhere between {{WARN}} and {{INFO}} for my purposes. I
would use this level to log when configuration settings changed or to log the
current value of configuration settings on application startup.
Currently, the {{Logger}} API provides no mechanism for me to use anything
outside the {{Level}} levels. I must choose one of those for logging my
{{CONFIG}} events. So then how do I use {{CONFIG}}? Well, I have to define a
{{Marker}}. Then I have to use both a {{Level}} (probably {{INFO}}) and a
{{Marker}} on my {{CONFIG}} events. Then I have to properly configure a
{{Filter}}, and get it in the correct place, to intercept those logging events
and inspect the {{Marker}}. All of this is much more difficult than simply
using this line of code:
{code:java} logger.log(MyLevels.CONFIG, "The current config setting is
{}.", setting);{code}
Now, what could {{MyLevels.CONFIG}} be? Two comments above this one, Paul
suggests that it should be an {{int}}, and that we should add methods to the
{{Logger}} API to accept an {{int}} that can be compared to the other {{Level}}
constants and logged appropriately. Why? So that {{Logger}} can have
_*SIXTEEN*_ more methods than it already does? Why not just re-use the methods
that accept a {{Level}}? And that's not even including the {{throwing}} and
{{catching}} methods, so actually eighteen new methods. How does this improve
the API but making {{Level}} extendable does not?
One way or another, I think it's a must for us to resolve a way to define your
own levels before Log4j can be released (and I so want to release it). Whether
that's making {{Level}} extendable or adding eighteen {{int}} methods to
{{Logger}} is a matter that merits discussion, but however it's done, it needs
to be done.
Four comments above, I provide a detailed example of how {{Level}} can be made
extendable _*without breaking the API*_. It's a binary-compatible change.
Existing code compiled against Log4j would continue to work with my proposed
change. I've read five or six "seconds" to my proposal since I posted it in
March. It seems like a safe and powerful change to make, so I'm bringing it
back up for discussion in the hopes that it will at least trigger some new
ideas, if not some agreement.
> 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 was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
