I've read through the proposal and although this provides a mechanism for cleanly obtaining seperate logging heirarchies based on some application component attribute, what is missing is how the configuration of the heirarchy fits in. For example in the CRS prototype, whenever a Heirarchy is created I would expect the container to attempt to apply the application specific configuration of category thresholds and associated appenders. This is a container specific step, but leads to the following questions:
- In the absence of a Hierarchy specific configuration being applied, does the new Hierarchy inherit all of the default Hierarchy's configuration? - If an application component configuration is to be applied to the new Hierarchy the container most likely would like to prevent modification of its own appenders. An application component should not be able to reconfigure or replace the server console or log files for example. With the current api I can't see how this can be done in general. - How can logging tools such as chainsaw gain access to the available active LoggerRepository instances? Since the RepositorySelector only provides a singleton view that has to be multiplexed based on the container specific details this leaves no mechanism I can see for tools to interact with the new dimension of application based repositories. Perhaps the RepositorySelector needs to also provide a Map of the <key, LoggerRepository> pairs. [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
