On Jul 29, 2005, at 8:21 PM, Aaron Mulder wrote:
On Fri, 29 Jul 2005, Dain Sundstrom wrote:
Before Aaron got his hands on it you used to be able to modify the
log4j configuration file via the management interface, but it looks
like he remove that "feature". Aaron is a lot more clever than I am,
so hopeful he can come up with something better than I did :)
Now now, no crazy accusations. I don't believe I've removed
anything, even the despised applet that lets you drop tables in the
system
database. :)
:)
I assumed the config file poller would only apply the config file
if it had been updated. So that you could change things in the
console,
and if you then altered the config file it would overwrite your
console
change, but if you just wait for the poller timeout it wouldn't revert
back to the config file version. Is that not correct? I'm OK with
the
"last change wins" style. I wouldn't be too happy if the file poller
automatically reverted anything you did in the console.
I actually was talking about the log service not the portlet. The
service used to have a setConfiguration(String configuration) method
that would overwrite the file. I know you love dangerous stuff like
that :) The code is here:
http://svn.apache.org/viewcvs.cgi/geronimo/trunk/modules/system/src/
java/org/apache/geronimo/system/logging/log4j/Log4jService.java?
rev=57150&view=markup
I'm really not sure what the best thing to do here. Another thing to
think about is do we want these changes to be persistent.
But the truth is, I don't think changing the overall system log
level is all that useful -- I'd much rather see a feature that let you
change the threshold for an individual appender (for example, to
turn up
or down the console output). I'm not sure about whether that should
rewrite your config file or defaults for next time. I guess maybe it
should update the default starting console log level, which as far
as I
know is coming from a static variable right now. We'll have to
think that
through -- we'd want to automatically disable the progress bar if the
level was below WARN, for example.
I agree that we really need more specific control then "global". I
just have no idea what to do here; good thing it isn't my problem
anymore :)
-dain
