At 01:03 28.06.2002 -0700, Scott M Stark wrote: >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:
The container could indeed add a glue for configuring log4j for a each web-application. This is a container specific step. It is very important to note that although highly useful this step is optional. The container can chose to leave the configuration step to the user (i.e. the webapp developer). One case that we have not discussed is letting applications use the same repository. The applications must have a way of letting the container know which clearly requires direct support from the container. This contradicts my previous statement. Container support in deployment descriptors is unavoidable. >- In the absence of a Hierarchy specific configuration being applied, does >the new Hierarchy inherit all of the default Hierarchy's configuration? No, definitely not. If logging for the webapp specific logger repository (=hierarchy) is not configured, it is not configured. The user will get the dreaded: log4j:WARN No appenders could be found for logger (com.wombat.XYZ). log4j:WARN Please initialize the log4j system properly. (In future log4j releases, this message will be modified to include information about the hierarchy as well, e.g. suffixing the hierarchy name.) Log4j does not have any default appenders or a default configuration. There is no reason to change this in webapps. >- 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. As long the Container's logger hierarchy is inaccessible to application components, the application cannot meddle with Container's logging. >- 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. Chainsaw just receives logging events. It does not have to know anything about the LoggerRepository. Nevertheless, the point about interacting with the set of logger repositories is an important one and having a <key, LoggerRepository> based map accessible through the RepositorySelector is a reasonable solution. For security reasons (see the previous point) this should have restricted access. I realize that your questions are related to each other. My replies provide only partial answers. >[EMAIL PROTECTED] -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
