Page History

1. Ability to produce a broker wide log which may or may not include the activity of virtual hosts
2. Ability to produce separate logs for each virtualhost
3. Ability to assign/change the level of any logger at runtime.  It will be possible to assign the logging level on a logger related to a class e.g. o.a.q.X or hierarchy e.g. o.a.q.
   
4. Logger levels can be assigned durably or non-durable.  Those durable will survive a restart.
5. Ability to assign different logger levels for different virtual hosts.
6. Ability to logs to different destinations, e.g.
   1. to a plain file on the filesystem
   2. to a stream
   3. to a bounded buffer
7. Logging configuration will be persisted to the Broker/Virtualhost configuration stores.  As such in the HA use-case, the same logging configuration will be applied to all nodes within a HA group.
8. Ability to configure file rolling and compression
9. Ability to configure logging and view logs from Web Management Console, REST API and later AMQP management.
10. Ability to limit who may configure logging or who may view logs via the Management interfaces.

Open Questions

1. Do we want the ability to view a log file that is on disk from Management, or is the ability to view the log messages within the bounded buffer recorder sufficient?  Assuming the answer is yes, and we need to retain the ability to stream the contents of an existing log from disk in a secure manner.
2. As logging configuration is to be unified into the store and substantial code is required to open/upgrade/recover the store, there is a possibility that an unexpected problem may occur before logging is configure.   It would seem sensible to have a emergency mode (command line switch) where we fall back on a simpler logging configuration that can be configured early.
3. Related to 2), in normal operation logging won't be ready until after the store is recovered.   Do we want to use a temporary appender to cache the logging the events then replay them once logging is ready???