Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 40173 invoked from network); 12 Dec 2002 17:32:10 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 12 Dec 2002 17:32:10 -0000 Received: (qmail 19512 invoked by uid 97); 12 Dec 2002 17:32:54 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 19464 invoked by uid 97); 12 Dec 2002 17:32:53 -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 19425 invoked by uid 98); 12 Dec 2002 17:32:53 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-Id: <5.1.0.14.0.20021212182716.0252bee8@mail.qos.ch> X-Sender: ceki@mail.qos.ch X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Dec 2002 18:31:47 +0100 To: "Jakarta Commons Developers List" From: Ceki =?iso-8859-1?Q?G=FClc=FC?= Subject: Re: JNDI based selection In-Reply-To: <5.1.0.14.0.20021211104203.026d9be8@mail.qos.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Costin Manolache wrote: > One comment: application isolation is not a voluntary thing. If we > want to isolate the loggers you can't allow the application to specify > what logger it wants in web.xml and hope they'll not use the same > name. 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. 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? -- Ceki -- To unsubscribe, e-mail: For additional commands, e-mail: