Dynamic log configuration

Goals:

• logging.properties is not required per application
• simple logging configuration is possible via config
• advanced logging configuration, including changing handlers, requires a logging.properties file

Alternatives

Would it be more work to provide a command line option (leveraged by the AB) to promote config/logging.properties file that the developer can then edit ? Something like zero promote config/logging.properties - The advantage to using a logging.properties file is that existing Java users do not have to understand the zero.config based logging settings. Systems programmers and the Zero development team can obtain and create a logging.properties file. OTOH, if this is for the script developer, then using the zero config specification makes more sense. How would this work for PHP scripts ? [Steve]Good point. We could go that route. Or we could map everything into zero.config. Maybe we should consider the latter.[/Steve]

Config

Logging properties will be expressed as a map in Zero config. For example:

logging.properties snippet:	config equivalent:
.level = SEVERE zero.core.events.level = ALL	/config/log = { ".level" : "SEVERE", "zero.core.events.level" : "ALL" } OR /config/log = {} /config/log#.level = "SEVERE" /config/log#zero.core.events.level = "ALL"

After config load, an initializer is invoked to drive /config/log settings into the LogManager.

Note that the config file is reloaded on every recycle. Users can force a recycle by invoking zero restart (should rename to "recycle" under bug 3866).

CLI tasks?

Do we need to offer CLI tasks? Config is sufficient for places where recycle is acceptable. For cases where the application cannot be recycled (e.g. debugging a long-running application), CLI tasks would be helpful.

We don't have a requirement for this, so will not develop the tasks yet. However, will capture some of the discussions for the record:

• CLI tasks could affect the LogManager directly for write-only support, but it's difficult to get the current "config" out of the LogManager. Would want to have a map of the current settings for read support. Seems that map should be persisted across recycles, e.g. the /app zone.

• Another option would be to hard code support in the ConfigZoneHandlerImpl for the /config/log key: Changes would be applied to the LogManager automatically. At that point, the log config could be treated as standard GC data and we could provide a set of GC accessor CLI tasks (e.g. =zero zget /config/http/port).