commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: JNDI based selection
Date Thu, 12 Dec 2002 17:58:32 GMT
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>


Mime
View raw message