I did not made the decision, but I know from my experience, that as you increase the number of log levels, their meaning become very subjective. The severity of the current set of levels in Logback can be understand relatively easily and the fixed set provides interoperability between different tools, applications and libraries. For example, syslog has four sublevels for errors: Emergency, Alert, Critical, Error. A developer has no chance to determine in advance what error conditions will count as an Emergency, which will require Alert procedures, which error conditions are critical and which ones are errors, but non-critical. He cannot even establish a specific order between error conditions, because that is, again, site specific and even within a single site it will change over time. Moreover, developers will differ. What seems to be Critical for one developer of one applicaton will be Emergency for another developer of another application/library. Assignment of administration procedures to specific conditions should be configured in tools, not hard coded in source code. On 2013.01.06. 23:15, Mark Petrovic wrote:
Thanks.
My question is not how I work around a finite and inextensible set of Levels, but why the design decision to make Levels final at all.
On Jan 6, 2013, at 1:05 PM, ceki <ceki@qos.ch> wrote:
Instead of levels, you can tag log statements with markers which are part of the SLF4J API. See [1] and [2].
[1] http://tinyurl.com/a5jogy8 [2] http://www.slf4j.org/api/org/slf4j/Marker.html
On 06.01.2013 20:49, Mark Petrovic wrote:
In Logback, Levels are final, meaning one cannot extend them to create new levels. I have no problem with this, but my users are wondering about it. Can you explain? Thank you.
-- Mark
-- Ceki 65% of statistics are made up on the spot _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user