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 > > > >
