In general I would like to be able to have a consistent mechanism for
configuration, unfortunately the design of the logging systems
prevent this. At any time any pice of code in the server can
reconfigure the logging system, and there are some application that
do this. Also most Java admin know how to configure Log4j and there
are many extensions that can be plugged in via the standard
configuration files. This is why I remove most of the code that
tried to "manage" Log4j and util.Logging.
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 :)
-dain
On Jul 29, 2005, at 6:31 PM, Matt Hogstrom wrote:
I think the setter should remain so the change can be done
programatically.
Perhaps the setter should update the corresponding persitent property.
Before fixing the individual issues I think we need to step back
and look at
how we want the user to interact with the Geronimo server. It is
confusing
to use the console to set some values, edit property files to
modify others.
The scope and contract of the changes and their mechanisms needs to
be well
thought out. Otherwise we'll end up with a hodge podge of
configuration. I
won't go into detail here as there is already another thread about
config
changes.
Its excellent that these discussions are happening as this
experience will
in many instances make or break a user experience. Speaking only from
experience with other commercial offerings that make mgmt of the
runtime to
a whole new level of complexity and will keep specialists employed for
years.
- Matt
----- Original Message -----
From: "Joe Bohn" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, July 29, 2005 3:17 PM
Subject: Re: possible bug/enhancement - Setting the log level
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
