Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 69618 invoked from network); 12 Dec 2002 18:08:44 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 12 Dec 2002 18:08:44 -0000 Received: (qmail 12102 invoked by uid 97); 12 Dec 2002 18:09:53 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 12071 invoked by uid 97); 12 Dec 2002 18:09:51 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 12057 invoked by uid 98); 12 Dec 2002 18:09:51 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) To: commons-dev@jakarta.apache.org X-Injected-Via-Gmane: http://gmane.org/ Path: not-for-mail From: Costin Manolache Subject: Re: JNDI based selection Date: Thu, 12 Dec 2002 09:58:32 -0800 Lines: 52 Message-ID: References: <5.1.0.14.0.20021211104203.026d9be8@mail.qos.ch> <5.1.0.14.0.20021212182716.0252bee8@mail.qos.ch> NNTP-Posting-Host: 64.84.39.162 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8Bit X-Trace: main.gmane.org 1039716480 16118 64.84.39.162 (12 Dec 2002 18:08:00 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 12 Dec 2002 18:08:00 +0000 (UTC) User-Agent: KNode/0.7.1 Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 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: For additional commands, e-mail: