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_______________________________________________
user mailing list
[email protected]
http://www.slf4j.org/mailman/listinfo/user
