Ceki Gülcü wrote:
> OK, the solution I presented solves the "VOLUNTATRY separation of
> logging" problem. It can be further refined to address the
> "MANDATORY separation of logging" problem Costin mentions.
> Costin suggested the use of string prefixes to enforce mandatory
> separation which is quite a nice idea.
>
> One possible approach is to have the string values stored in JNDI to
> be prefixed by the host name if requested to so by the <host> element
> within the server.xml file. Thus, the log4j repository selector can
> provide a host specific logger hierarchy for the hosts that request
> the service. Moreover, the host specific logger hierarchy cannot be
> spoofed by other hosts living in the same container. Looks like we
> have got a solution to the mandatory logging separation problem.
The prefix should be set by container - and it should probably be
the "canonical" name of the application.
One remaining issue is if we allow apps to open loggers of a different
app. getLog() needs to check if a prefix is already present - and
if so do a permission check ( that would need JDK1.2 - but can be
implemented in a LogFactoryImpl ).
> Now, this solution requires that the Container directly provide
> support for log4j. Will Tomcat do that? Probably not, at least not
> until all the other containers do. How ironic would that be?
This has nothing to do with other containers.
If we add the jndi stuff to commons-logging, tomcat will set the
"prefix" env and it can also set other jndi properties that
are needed. Both log4j and commons-logging could use this info.
And of course, if LogFactory implements this lookup, then
it'll separate the loggers regardless of implementation ( we
may have a problem if both c-l and log4j are adding the prefix :-)
We already include commons-logging-api and we're in process of
migrating all the internal logging to c-l, and separating the
loggers is an important issue.
I think it would be a good idea to include log4j and log4j
specific hooks in tomcat5 - but that's an issue for tomcat-dev.
There are already some discussions about the content of the
5.0 release and increased modularity ( and a better hook system
and support for JMX ).
Costin
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
|