That's what I hacked for my use. Ceki, if you can include this in the
default getInstance() impl.
If you need getContextClassLoader for JDK1.1, you can use few existing -
and very nice - implementations: either in xalan or xml-commons jaxp, or (
my favorit :-), tomcat.util.compat ( which is faster since it's not used
on any introspection, and has some other nice tools ). Or, in the great
tradition of jakarta, you can reinvent your own :-)
The code is quite simple, and I would sugest anyone using log4j in a
servlet/ejb environment to use something like that to get the logger.
AFAIK something similar shuld be used for Logging and LogKit ( the latest
seems to have something in that, but still has the defaultHierarchy and
that's probably what people use - otherwise you have to create a hierarchy
and pass it around in all the classes ).
It's not perfect either, but solves my first itch :-) I hope a more
complete solution will be implemented.
You can use it outside any logger that has hierarchies support, or
(better) inside the implementation of the logger ( i.e. next version of
log4j if Ceki likes my patch ).
It is based on the assumption that each webapp has a separate class
loader, that the class loader is set as context class loader ( in JDK1.1
we don't have much security anyway, so no need to worry ), and that it's
not possible from one webapp to forge the context class loader ( if it
can, it means it's trusted code with "AllPermissions", so it can do
anything anyway ).
private static Hashtable hierarchies=new Hashtable();
public static Category getInstance(String name) {
// First, find the (guarded) hierarchy
ClassLoader cl=Thread.currentThread().getContextClassLoader();
if( cl==null ) {
// Top level or system - use this class loader
cl= Log4j.class.getClassLoader();
}
Hierarchy h=(Hierarchy)hierarchies.get( cl );
if( h == null ) {
Category rootC=new Category("");
h=new Hierarchy(rootC);
hierarchies.put( cl, h );
}
return h.getInstance( name );
}
Costin
