of these classes in pre-1.4 JVMs. Without this, an InvocationTargetException
could be thrown when calling the constructor but that could also be caused
by a number of other reasons which we don't want to ignore.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@179529 13f79535-47bb-0310-9956-ffa450edef68
* Use static initialiser block to initialise factories rather than variable initialiser.
* Add static member thisClassLoader to cache classloader for the LogFactory class;
change all calls to LogFactory.class.getClassLoader() to just use thisClassLoader.
* Change getContextClassLoader to always use AccessController (actually, rename
getContextClassLoader to directGetContextClassLoader, and make getContextClassLoader
a wrapper around that).
* define a method getClassLoader(clazz) that just does clazz.getClassLoader for now;
change all calls to clazz.getClassLoader into getClassLoader(clazz)
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@170501 13f79535-47bb-0310-9956-ffa450edef68
Turned a complicated anonymous class declaration into a simple anonymous class that calls a method
on LogFactory containing all the code previously within the anonymous class declaration.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@170355 13f79535-47bb-0310-9956-ffa450edef68
This can happen in JDK1.1 and in embedded systems work. Without this
fix, a new LogFactoryImpl is created each time LogFactory.getLog(..)
is called! See bugzilla#10825, comment#22. Thanks to Erik Erskine for
bug report and fix.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@169387 13f79535-47bb-0310-9956-ffa450edef68
Simon Kitching