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

["Nick Williams (JIRA)" <ji...@apache.org>]

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