FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Solaris, linux, windows (this is a generic code problem)

A DESCRIPTION OF THE PROBLEM :
I think this bug might be related to Bug# 6231328
Basically, the LogManager does not check the ContextClassLoader when trying to load a log handler. This occurs several times in the LogManager source code, so if a class that defines a new handler is instantiated from a new (non system) ClassLoader that defines the location of the handler (i.e., not on the default classpath), the LogManager will throw an exception b/c it is only checking the SystemClassLoader.

The LogManager should be checking the contextClassLoader when loading any user defined log handler. Looking at the LogManager source, this is correctly done in a couple of locations but for some reason not done in other locations.
E.g., line 160-168 it is done correctly:
160 cname = System.getProperty("java.util.logging.manager");
161 if (cname != null) {
162 try {
163 Class clz = ClassLoader.getSystemClassLoader().loadClass(cname);
164 manager = (LogManager) clz.newInstance();
165 } catch (ClassNotFoundException ex) {
166 Class clz = Thread.currentThread().getContextClassLoader().loadClass(cname);
167 manager = (LogManager) clz.newInstance();
168 }

Shouldn't this be done any time a user modifiable logging property is retrieved???
e.g., line 890 checks ClassLoader.getSystemClassLoader().loadClass(word);
but not the Thread.currentThread().getContextClassLoader()
This occurs several times throughout the code:
lines: 355, 410, 732, 890
Seems like an easy enough fix!


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Load a class that uses the LogManager and specifies a log handler. Load that class from a user defined ClassLoader that contains the classpath to the log handler. Do not put the classpath to the log handler in the SystemClassLoader.

REPRODUCIBILITY :
This bug can be reproduced often.

CUSTOMER SUBMITTED WORKAROUND :
Include the location of the handler class on your initial (System) classpath