http://bugzilla.slf4j.org/show_bug.cgi?id=206 Robert Elliot <robert@teviotia.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |robert@teviotia.co.uk --- Comment #1 from Robert Elliot <robert@teviotia.co.uk> 2010-11-30 11:00:01 --- SLF4J is an interface, not a logging system. You could write an implementation that sent all log messages to sys out if you wanted, regardless of level. So setting the level in SLF4J makes no sense. You set the level on the logging system you are using as your SLF4J implementation - Log4j or Logback. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

http://bugzilla.slf4j.org/show_bug.cgi?id=206 --- Comment #3 from Ron Gross <ron.gross@gmail.com> 2010-11-30 14:30:15 --- So, in other words, it is a design choice not to include any filtering inside SLF4J, but rather let the implementations do the filtering, right? Thanks. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

http://bugzilla.slf4j.org/show_bug.cgi?id=206 --- Comment #5 from Robert Elliot <robert@teviotia.co.uk> 2010-11-30 15:23:54 --- The right design decision in my opinion - it's the job of the interface to say "here's a message of DEBUG importance". What to do with that message - print it to the console, write it to a file, stick it in a database etc. - is the job of the implementation. And choosing to discard it (because of a logger level) is doing something with it. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

http://bugzilla.slf4j.org/show_bug.cgi?id=206 --- Comment #7 from Robert Elliot <robert@teviotia.co.uk> 2010-12-02 11:33:26 --- Since you're inclined to argue, I would say that even if you are correct and there "all _feasible_ implementations of SLF4J should ... filter messages by their level", adding this capability to the SLF4J API incorrectly mixes the two concerns of logging a message and choosing what to do with that message. As it stands the SLF4J API only deals with the concern of logging a message, and leaves what to do with it entirely to the implementation. This means that if a library you depend on depends only on slf4j-api you can be confident that it does not do anything to alter the logging configuration of your application*, which is as it should be - a library has no business deciding for the end application what log statements it is or is not interested in. And it also means that as a library developer you can be confident that you are not doing anything bad like that so long as you just depend on slf4j. A nice clear separation of concerns. The end application is the appropriate place to decide what logging message should go where, and of course the end application knows what slf4j implementation is being used and can configure it directly. I disagree with your original thesis, though - I don't think SLF4J should be makign as all encompassing a claim as that "all _feasible_ implementations of SLF4J should ... filter messages by their level". It may make perfect sense for some to keep all logged data for some reason, or to filter it on some basis other than level. In general an interface should be very wary of daring to predict what might constitute the set of all feasible implementations. There is already an slf4j implementation that does no filtering, and uses the level solely to print it at the front of the message - slf4j-simple. * assuming it doesn't do anything really malicious with reflection -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.