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
