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

[Jacob Kjome]

I think you are confusing the issue.  From the archived post you 
cited below, Boris is correct in saying that your own code shouldn't 
have code that programatically configures the logging 
system.  However, that doesn't mean that you can't use an separately 
deployed dedicated MBean that performs configuration for your logging 
implementation of choice.

What I've used for programmatic Log4j configuration to great success 
is LogWeb.  I deploy it separately from my own webapp to provide a 
web-based logger configuration interface.   This is under Weblogic 
with Log4j in the System classpath and no repository selector, so it 
configures logging for the entire sever (LogWeb can also be 
integrated with your own app as well, but I think that's only useful 
under a server like Tomcat which uses child-first 
classloading.  Unfortunately, LogWeb only recognizes the default 
logger repository so it's not so useful if you are using a repository 
selector.).  My webapp doesn't have a lick of code dealing with Log4j 
configuration in this case.  All I do is pull up the LogWeb webapp, 
tinker with the logging system there, and logging behavior is changed 
for the server, my app, and any other apps using Log4j on the 
server.  If I ever decided to move to a different logging 
implementation, I could use a different web-based or MBean interface 
that allows controlling configuration for that implementation.  My 
webapp never knows the difference.

See here for LogWeb and other useful Log4j related resources....
http://wiki.apache.org/logging-log4j/Log4jRelatedResources


Jake

At 03:07 PM 8/30/2007, you wrote:
>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-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>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
>
>
>Boardwalk for $500? In 2007? Ha!
><http://us.rd.yahoo.com/evt=48223/*http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow>Play 
>Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
>_______________________________________________
>user mailing list
>user at slf4j.org
>http://www.slf4j.org/mailman/listinfo/user