commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shaun Laws" <shaunl...@hotmail.com>
Subject Re: LogConfigurationException using Junit and Digester
Date Thu, 15 Jul 2004 15:49:22 GMT
Thanks for your help Simon. I am not doing anything with a custom 
classloader. Nor fiddling with the bootclasspath. I used the trivial class 
as you suggested and I still get the same LogConfigurationException with my 
trivial class - as you suspected Digester is not the problem. I will take a 
closer look at my Java setup.

Shaun


>From: Simon Kitching <simon@ecnetwork.co.nz>
>Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
>To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
>Subject: Re: LogConfigurationException using Junit and Digester
>Date: Thu, 15 Jul 2004 12:09:14 +1200
>
>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: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>

_________________________________________________________________
Get tips for maintaining your PC, notebook accessories and reviews in 
Technology 101. http://special.msn.com/tech/technology101.armx


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message