Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 14317 invoked from network); 15 Feb 2002 18:49:29 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 Feb 2002 18:49:29 -0000 Received: (qmail 491 invoked by uid 97); 15 Feb 2002 18:49:21 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 446 invoked by uid 97); 15 Feb 2002 18:49:21 -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 405 invoked from network); 15 Feb 2002 18:49:20 -0000 Date: Fri, 15 Feb 2002 10:49:16 -0800 (PST) From: "Craig R. McClanahan" To: Jakarta Commons Developers List Subject: RE: cvs commit:jakarta-commons/logging/src/java/org/apache/common s/logging/implLogFactoryImpl.java In-Reply-To: <458473676F1AC74A84EAB2F22004DA6D1B20D8@mail.nextance.com> Message-ID: <20020215103959.J7520-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 15 Feb 2002, Scott Sanders wrote: > Date: Fri, 15 Feb 2002 09:53:10 -0800 > From: Scott Sanders > Reply-To: Jakarta Commons Developers List > To: Jakarta Commons Developers List > Subject: RE: cvs > commit:jakarta-commons/logging/src/java/org/apache/common > s/logging/implLogFactoryImpl.java > > Costin, > > I don't think you answered the question. If I use Digester in two > different web applications on the same server, how does Digester know it > is being used in this way? It doesn't. It is the responsibility of the > container to protect this situation, and I don't even see how Digester > is going to use commons-logging to have this happen. Tomcat would have > to make this happen. > > Scott > The HEAD branch of Digester already uses Commons Logging. It creates a Log instance per Digester instance (i.e. it's not static) via the new discovery mechanism: protected Log log = LogFactory.getLog("org.apache.commons.digester.Digester"); Note that, with the changes that Costin recently checked in, you can install commons-logging.jar and commons-digester.jar in Tomcat's shared library directory, use them in webapps, and still have independent logging configurations per webapp. That's because the discovery algorithm creates a LogFactory instance per class loader, and each webapp gets its own. This doesn't cover all possible multi-hierarchy cases, but it's a common one. Also, if a component wants to, it can even expose a setLogger() method to let the application change the default (Digester does that as well). Craig > > -----Original Message----- > > From: costinm@covalent.net [mailto:costinm@covalent.net] > > Sent: Thursday, February 14, 2002 7:51 PM > > To: Jakarta Commons Developers List > > Subject: RE: cvs > > commit:jakarta-commons/logging/src/java/org/apache/common > > s/logging/implLogFactoryImpl.java > > > > > > On Thu, 14 Feb 2002, Steve Downey wrote: > > > > > If LogFactory.getLog(getClass()) isn't safe, then security is > > > hopeless. The only way it can be safe is if the container > > arranges for > > > it to be safe. Not exposing the container's logging to the > > webapps is > > > necessary, although not sufficient. Using separate classloaders for > > > each webapp is also probably required. > > > > What I mean is: if Digester.getLog( getClass() ) calls log4j's > > Category.getInstance( "org.apache....Digester" ), and log4j > > is installed > > in the common class loader, then all webapps using Digester will have > > their log go to the same place. Think about a hosting service > > ( ASP ), you don't want customer's logs mixed. > > > > The LogFactory must be able to support independent hierarchies. It is > > mostly the job of the logger implementation - but the API and the > > wrappers it provides must also support this. For example > > LogFactoryImpl is caching instances - so if installed in the > > common loader it'll fail to separate apps, regardless of the > > underlying logger. > > > > Please don't assume the logger will only be loaded in a leaf > > class loader ( i.e. by the webapp, and not in commons ). I > > would point again to JAXP - at the beggining you would just put it > > in the webapp and work. But then it started to be used in the > > container, and took a rewrite of the container class loader > > to make it > > possible to use different parsers in different apps. And now > > JAXP is part of JDK1.4, in rt.jar. > > > > I don't think commons-logging will end up in JDK1.5, but it's > > likley it'll be used in tomcat and in components that have to > > be in the common loader. And hopefully tomcat will 'plug' > > into the logger - at least to flush the buffers when shutting > > down, and more importantely in sandbox mode, to provide the > > doPriviledged blocks that will be required. > > > > If you are in a sandbox - no file logger will work. The only > > way to log in a file ( or socket, etc ) is to have the > > commons-logger.jar in a special location with granted privs, > > and use doPriviledged() to allow webapps to log. > > > > I can't imagine a good way to do that without having > > commons-logger in a common class loader. > > > > > > > In any case, the underlying logging package *has* to > > provide the same > > > facility. Otherwise, using the native logging api would subvert > > > security. > > > > The API must be designed with security and container-use in > > mind - it's > > extremely hard to add it back later. Of course the underlying > > logging package has to be secure - but if the logging API is > > caching the > > Log keyed on name it'll just brake whatever the logging impl. does. > > > > Now we use the thread class loader as a namespace - and we're > > ok. A guard or similar mechanism is still needed if you want > > to share logs between apps - but that's probably not a big priority. > > > > > > Costin > > > > > > -- > > To unsubscribe, e-mail: > > unsubscribe@jakarta.apache.org> > > For > > additional commands, > > e-mail: > > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: