On Thu, 2004-07-15 at 03:24, Shaun Laws wrote:
> I keep getting a LogConfigurationException whenever I make the call:
>
> Digester digester = new Digester()
>
> I stripped out my code to the point where the following minimal code
> produces the exception:
>
> package com.webcredenza.util.paymentprocessor.test;
> import org.apache.commons.digester.Digester;
> import junit.framework.*;
>
> public class JunitTest extends TestCase {
>
> public void testFactoryCCConfigFileNoProcessor() {
> try {
> Digester digester = new Digester();
> }
> catch (Exception ex)
> {
> ex.printStackTrace();
> }
> }
>
> public static Test suite() {
> TestSuite suite = new TestSuite(JunitTest.class);
> return suite;
> }
>
> public static void main(String[] args) {
> junit.swingui.TestRunner.run(JunitTest.class);
> }
> }
>
> A snippet of the stack trace showing the call made by the JUnit framework to
> the test method and the subsequent call to the Digester constructor:
>
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.))
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:370)
> at org.apache.commons.digester.Digester.<init>(Digester.java:346)
> at
> com.webcredenza.util.paymentprocessor.test.JunitTest.testFactoryCCConfigFileNoProcessor(JunitTest.java:9)
>
> Has anyone out there seen this problem before. I'd be grateful for any
> suggestions as to how to avoid it.
>
That's very weird. I can't understand how this exception is even
possible; normally when multiple copies of a class are present in the
classpath, the first one is used.
Maybe if you had a custom classloader which uses some mechanism other
than CLASSPATH to find its classes, or were using aspect-j to
dynamically modify loaded classes or something. But your testcase
implies that you aren't doing any such thing.
Has someone perhaps placed a copy of commons-logging into the
bootclasspath somewhere, eg in the $JAVA_HOME/lib/ext directory? Even
that wouldn't do it as far as I know, but it's worth a look.
You aren't using any -X options to the jvm to fiddle with bootclasspath
or similar, are you?
By the way, this is definitely not a Digester-related problem. Digester
uses commons-logging in a normal manner, without any strange
classloading tricks that might cause anything like this.
And it's probably not a problem in commons-logging either; I suspect
there's something very odd with your java setup.
Could you try writing a trivial class of your own which simply does this
in the constructor:
Log log = LogFactory.getLog("stuff");
then try using this in your testcase instead of the Digester class? This
should eliminate Digester as the cause of the problem.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
