On Fri, 15 Feb 2002, Scott Sanders wrote:
> Date: Fri, 15 Feb 2002 09:53:10 -0800
> From: Scott Sanders <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > 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-> [EMAIL PROTECTED]>
> > For
> > additional commands,
> > e-mail: <mailto:[EMAIL PROTECTED]>
> >
> >
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
