My $0.02...
It seems to me that the only immediate decision that needs to be made is what
the Level class should consist of. Should it be a straight-up enum or Nick's
extensible enum?
Given that Nick's extensible enum allows for so much more
flexibility/extensibility, it also seems to me that unless someone produces a
valid argument against it then it's a no-brainer that we go with it.
Talk of adding more "official" log levels and how/whether they should show up
in the API is a completely separate issue and should not be confused with
Nick's original proposal for Level as an extensible enum.
Jake
On Wed, 27 Mar 2013 09:49:51 -0500
Nick Williams <[email protected]> wrote:
On Mar 27, 2013, at 9:36 AM, Gary Gregory wrote:
I think we can discuss both issues separately: (1) more level and (2) how
they show up in the API.
(1) Let's discuss the merits how more log levels. Should we go the Apache
HTTPD route? version 2.2? 2.4?
(2) Then let's discuss if and how they should show up in the API.
v2 is the best time to add new levels. More APIs can be done later. For
example the trace APIs can map to TRACE1 and all other TRACE levels can be
used with the log(Level,...) APIs.
If we do not add levels in v2 then we need to allows "space" for them by...
what? not using int 0, 1, 2... for the current levels and using 0, 100, 200…?
That's what I did with my extensible enum: made each built-in value a
multiple of 100 so that custom values could be inserted in between. :0)
Gary
On Tue, Mar 26, 2013 at 2:19 PM, Ralph Goers <[email protected]>
wrote:
I am not in favor of adding 9 or 10 new sets of methods to the Logger
interface.
Ralph
On Mar 26, 2013, at 11:10 AM, Gary Gregory wrote:
Hm, I can see having an API that let's in custom "int" levels would satisfy
some cases. But why not consider adding more built-in levels? See the thread
on the ML.
Apache HTTPD 2.2 has 8 levels:
https://httpd.apache.org/docs/2.2/mod/core.html#loglevel
Apache HTTPD 2.2 has 16 levels:
https://httpd.apache.org/docs/2.4/mod/core.html#loglevel
On Tue, Mar 26, 2013 at 1:47 PM, Paul Benedict (JIRA) <[email protected]>
wrote:
[
https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614354#comment-13614354
]
Paul Benedict commented on LOG4J2-41:
-------------------------------------
I don't support departing from Java enums. We should keep a strict and
limited set of provided levels. To help others who definitely believe they
need custom levels, we should provide (1) a method that takes an int that
identifies their level and (2) a custom strategy that knows how to deal with
it.
> 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.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
E-Mail: [email protected] | [email protected]
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
--
E-Mail: [email protected] | [email protected]
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
