You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Ceki Gülcü <ce...@qos.ch> on 2002/06/27 16:11:42 UTC
Logging separation
Hi everyone,
I have written a small specification for tacking the logging
separation problem in servlet containers. It is available here:
http://qos.ch/containers/sc.html
Please do not hesitate to forward this email to forums where Container
developers hang around. I've already forwarded it to tomcat-dev@ and
jboss-dev@ mailing lists. Ietty, Resin, Orion, Websphere, Weblogic
developers are also a target audience. If you are involved with these
products I'd appreciate if you could inform the appropriate parties.
Many thanks in advance, Ceki
ps: My apologies for the noise. I assure you that it is exceptional.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging separation
Posted by Scott M Stark <Sc...@jboss.org>.
See below.
----- Original Message -----
From: "Ceki Gülcü" <ce...@qos.ch>
To: "Log4J Developers List" <lo...@jakarta.apache.org>; "Log4J
Developers List" <lo...@jakarta.apache.org>
Sent: Friday, June 28, 2002 3:28 AM
Subject: Re: Logging separation
> 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.
>
Leaving the config to the component is only going to work in simple
cases. If a user wants to view a collection of components as an application
that should share the same repository I think it will be difficult for them
to
achieve this.
> >- 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.
>
The container has already configured a Hiearchy and in the absence of an
application component specific config I would want to clone the root
category
config onto the new repository. Doable?
> >- 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.
>
If the container or application tries to apply a config like:
log4j.rootCategory=DEBUG, FILE, CONSOLE
log4j.appender.FILE=org.apache.log4j.FileAppender
log4j.appender.FILE.File=server.log
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c{1}] %m%n
log4j.appender.FILE.Append=false
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Threshold=INFO
log4j.appender.CONSOLE.Target=System.out
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c{1}]
%m%n
the configured categories may be different but the ultimate appender devices
are not. The only thought I have is introducing a notion of appender devices
to help define is a given appender trying to use the system out stream, the
server.log file, the admin JMS queue, etc.
> >- 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.
>
It needs to know about the LoggerRepository if it is only going to show
events
from a given application component. Likewise a tool that allows one to edit
the configuration of an application component category heirarchy at runtime
needs someplace to start.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging separation
Posted by Ceki Gülcü <ce...@qos.ch>.
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.
>Scott.Stark@jboss.org
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging separation
Posted by Scott M Stark <Sc...@jboss.org>.
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.
Scott.Stark@jboss.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>