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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
