commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: cvs commit:jakarta-commons/logging/src/java/org/apache/common s/logging/implLogFactoryImpl.java
Date Fri, 15 Feb 2002 18:49:16 GMT


On Fri, 15 Feb 2002, Scott Sanders wrote:

> Date: Fri, 15 Feb 2002 09:53:10 -0800
> From: Scott Sanders <ssanders@nextance.com>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> 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:
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> >
> >
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>


--
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