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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
