commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <>
Subject RE: cvs commit:jakarta-commons/logging/src/java/org/apache/common s/logging/
Date Fri, 15 Feb 2002 03:08:06 GMT

> -----Original Message-----
> From: []
> Sent: Thursday, February 14, 2002 1:50 PM
> To: Jakarta Commons Developers List
> Subject: RE: cvs
> commit:jakarta-commons/logging/src/java/org/apache/common
> s/logging/
> On Wed, 13 Feb 2002, Steve Downey wrote:
> > Any logging during construction would have to go to the 
> system default
> > logger. Whatever that is. 
> Not if you want the components to be useable in a secure ( 
> sandboxed ) 
> environment. 
> Costin

But how? Digester doesn't know about the customer's custom logging
hierarchy. It can get to the system default logging system by calling
LogFactory.getLog(getClass()). It doesn't have it's own log factory yet, as
it was just constructed. Now, the system default logger may have been
configured by some outside mechanism, but Digester (for example) can't do
it. In any case, even if there was some mechanism by which Digester could
get at a non system default logger, by your arguments, it can not be relied
on to do so. Substitute for Digester RandomThirdPartyComponent, or the
web-app itself.

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

In any case, the underlying logging package *has* to provide the same
facility. Otherwise, using the native logging api would subvert security.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message