logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Williams (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-41) Extensible Log Level
Date Mon, 25 Nov 2013 18:48:35 GMT

    [ 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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message