In my opinion that would seem like taking a step backward.
This is a setting which users (application server administrators) may
need to change quite often. Why would we want to bury that as a
property file update where the change isn't effective until the next
"refresh" interval (depending upon how much time as elapsed since the
last refresh)? It seems like the current implementation is an attempt
to approximate the capabilities that we have readily available with a
web console or command line.
The very reason for providing a Web Console (and command line API) is to
make these types of changes more user friendly. The change can be made
effective when the command is complete (or when the results are
displayed on the glass). We can still store the value in the properties
file and reference that at server initialization. However, once the
server is running I think that the only way to update the setting (aside
from another server recycle) should be via the GUI or a command api.
We could put some complicated logic in to store time-stamps and try to
let the most recent win, etc.... but that seems like overkill to me.
- Joe
Dain Sundstrom wrote:
On Jul 29, 2005, at 11:10 AM, Bruce Snyder wrote:
AFAICR, allowing a programmatic call to take precedence over the
.properties/.xml file can *only* take place programmatically.
Facilitating such a change might be possible by changing the way that
the log level is configured. But stopping the polling of a log file is
probably also not a good idea because someone may change this to
affect the log level *after* a programmatic call.
I agree. Maybe we should remove the setter.
-dain
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
