commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <>
Subject RE: cvs commit:jakarta-commons/logging/src/java/org/apache/common s/logging/
Date Fri, 15 Feb 2002 17:53:10 GMT

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.


> -----Original Message-----
> From: [] 
> 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/
> 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->>
> For 
> additional commands, 
> e-mail: <>

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

View raw message