Project Summary | Download


01-Nov-2005 jcleclipse 0.2.0 Released
  This release is fully commons-logging-1.0.4 compliant

Problem : JCL Classloader

Many jakarta project use commons-logging as their logging mechanism. But in some env, the JCL expose its classloader flaw, and make all software depend on it cannot running.

When JCL is wrapped in eclipse plugin and deployed with Java Web Start, the JCL's Log interface is loaded by caller's classloader - EclipseClassLoader, but the impl logger is loaded by thread context class loader, in this case, JNLPClassLoader. Since the logger class and Log interface are loaded by different classloader, the logger obj cannot assign to Log interface, so JCL will throw a exception

LogConfigurationException : Invalid class loader hierarchy. You have more than one version of org.apache.commons.logging.Log visible, which is not allowed.

One of the log4j initiator, Ceki Gülcü has written a good article describe JCL's classloader problem:
"Taxonomy of class loader problems encountered when using Jakarta Commons Logging"

JCL Eclipse plugin

Eclipse provide a plugins logging mechanism: ILog. When running with Java Web Start, bridging all logs to eclipse's native log is more convenient than bridging to other log impl, which need assign some individual log files.

Jcleclipse is a eclipse plugin wrapping the commons-logging-1.0.4. Instead of trying to resolve JCL's problem, jcleclipse just offer a logger impl - EclipseLogger and make a slightly modify on LogFactory to ensure loading the EclipseLogger without classloader problem.

In plugins env, the LogFactory always return EclipseLogger. In other env, the jcleclipse act exactly as the original one. By installing the plugin, it's much easier to develop plugins depend on JCL. You can test your plugins inside or outside plugin env without changing the plugin project's classpath.


The following system properties are supported to configure the behavior of the EclipseLogger:

SourceForge.net Logo