You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Bulbuk, Ole" <ob...@kelman.de> on 2001/02/20 18:05:10 UTC

Bug: Usage of Class.forName() in DOMConfigurator

Hi,

I have found a minor bug when using the DOMConfigurator.
When I hava the log4j.jar file in the CLASSPATH everything is working fine
but when I put it in the jre/lib/ext/ directory it won't find my Filters,
Context class etc.
This is because the DOMConfigurator is loaded by the extension class loader
which is a parent of the application class loader.
The fix is quite simple:
istead of:
  Class.forName(className)
use:
  Class.forName(className, true,
   Thread.currentThread().getContextClassLoader())

Now there is always the right class loader used. When a class from the log4j
package is requested the application class loader will automatically ask the
extension class loader first.
I don't know how other configurators behave.

As I mentioned in an earlier post I made some extensions to log4j. Some
people already requested the source code. If nobody objects I will send it
with a small test example to the list packed in a jar file.
But I will have to clean it up from some Kelman specifics first.

Regards,

Ole
-- 
Ole Bulbuk             Fon://+49/30/6576/3724
Kelman GmbH            Fax://+49/30/6576/3601
Haus 40                mailto:OBulbuk@Kelman.de
Koepenicker Str. 325   http://www.Kelman.de
12555 Berlin, Germany

Re: Bug: Usage of Class.forName() in DOMConfigurator

Posted by Anders Kristensen <ak...@dynamicsoft.com>.
What a curious little problem!  I suppose it makes some kind of sense
that extensions placed in jre/lib/ext/ should be self contained. That's
probably the intention.

There is an issue with the solution you propose, anyway, which is that
the 3-arg version of Class.forName() was introduced in JDK 1.2 and log4j
is JDK 1.1.x compatible.  

Presumably at some point we'll decide to sacrifice JDK 1.1 so your
proposal may still come in handy, only maybe not any time soon.

Anders


"Bulbuk, Ole" wrote:
> 
> Hi,
> 
> I have found a minor bug when using the DOMConfigurator.
> When I hava the log4j.jar file in the CLASSPATH everything is working fine
> but when I put it in the jre/lib/ext/ directory it won't find my Filters,
> Context class etc.
> This is because the DOMConfigurator is loaded by the extension class loader
> which is a parent of the application class loader.
> The fix is quite simple:
> istead of:
>   Class.forName(className)
> use:
>   Class.forName(className, true,
>    Thread.currentThread().getContextClassLoader())
> 
> Now there is always the right class loader used. When a class from the log4j
> package is requested the application class loader will automatically ask the
> extension class loader first.
> I don't know how other configurators behave.
> 
> As I mentioned in an earlier post I made some extensions to log4j. Some
> people already requested the source code. If nobody objects I will send it
> with a small test example to the list packed in a jar file.
> But I will have to clean it up from some Kelman specifics first.
> 
> Regards,
> 
> Ole
> --
> Ole Bulbuk             Fon://+49/30/6576/3724
> Kelman GmbH            Fax://+49/30/6576/3601
> Haus 40                mailto:OBulbuk@Kelman.de
> Koepenicker Str. 325   http://www.Kelman.de
> 12555 Berlin, Germany
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org