[slf4j-user] slf4j should support programmatic log level adjustment: seeking design rationale

[kip k]

Hi All,

I have an application in which I'd like to be able to programmatically adjust log levels.  In the current prototype, I have slf4j adapting log4j, and, while I see exactly how I might accomplish my goal in the latter API, I find no means to do this without subverting the slf4j facade we all know and love (viz. by coding to log4j directly).  prowling this mailing list's archive in the vain hope of a solution, I see several threads on this very topic:

http://www.slf4j.org/pipermail/user/2007-March/subject.html

http://www.slf4j.org/pipermail/user/2007-February/subject.html


Both, firstly, confirm that slf4j has no such functionality, and, secondly, suggest that the design deficiency is not in the slf4j api, but in the functional specification of the hapless engineer who would build this into their system.  For example:

(from http://www.slf4j.org/pipermail/user/2007-February/000252.html)
	in my personal opinion configuring loggers programatically is bad 
	practise and maybe
	the usecase has to be reviewed.While I would readily agree that this is not a feature required by every system, having worked on a number of large-scale embedded communications devices, I would proffer that it nonetheless is a core competency in many domains.  when dozens of independent tasks/threads/processes are all appending to the same log and a single wall-clock second might generate over a thousand
 messages (in a native code shared memory implementation), being able to selectively enable and disable logging is absolutely essential.  Since the system is always on, one has no recourse to resetting the system.  (the idea of even resetting the system for an ancillary component like a logging subsystem--as opposed to a traffic path--is odd even to suggest.)

While I am prototyping a pure software solution (to run on commodity hardware), this too will be always on.  Shutting down would drop traffic, and--since logging here functions primarily for debugging--would potentially increase our susceptibility to heisenbugs.  In short, I wish to create an MBean with two management operations: one which allows me to list all logger names, and another which takes a logger name and allows me to set its level.  There is clearly precedence for this: run any simple Java 5+ application with -Dcom.sun.management.jmxremote, inspect it with
 JConsole, and look at the java.util.logging domain's Logging MBean created in the platform MBean server.

My intent here is not to find fault with the cleanly written and well-designed slf4j software.  Obviously I think it's Good Stuff or we wouldn't be prototyping with it.  My hope is instead that its steering committee (i.e. Ceki) will reconsider the objection to this feature.  I don't dismiss the fact that not all logging frameworks provide a mechanism for programmatic log level adjustment.  Yet, I fail to see why that should leave users facing the ugly prospect of either abandoning slf4j or looking to run-time casts.  Why not emulate the approach taken by the java.lang.Thread API to solving the underlying problem of variation in thread priority semantics?  It is not a problem that the API makes no guarantees about how the JVM will interpret thread priority assignments; the fact that the API exists prevents
 clients from coding to a non-portable API.  When running on sophisticated platform, the code gets what it wants; when priorities aren't implemented, or are done so imperfectly, functionality degrades gracefully, without rendering the system useless.

best,

kip






       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-user/attachments/20070830/96bd0b09/attachment.htm>