commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Shelby <>
Subject Re: [configuration] Config + Digester NoSuchMethodException
Date Tue, 29 Jan 2008 21:30:03 GMT
This is one of those classloader issues that one just has to blame on  
JUnit.  When I took JUnit out of the picture and just ran the test  
classes directly through a new "main()" method, everything worked  
(mostly) just fine.

So something about JUnit's classloader (for 3.8.1 - I haven't tried it  
with 4.x yet) and Digester doesn't seem to want to get along.

I'll address the "mostly()" in my next email.

Thanks for looking at it,

Quoting Oliver Heger <>:

> Simon Kitching schrieb:
>> ---- schrieb:
>>> Quoting Oliver Heger <>:
>>>> schrieb:
>>>>> Quoting Oliver Heger <>:
>>>>>> schrieb:
>>>>>>> This is only happening on one box and I can't figure out why
>>>>>>>   because every other box with (seemingly) the same jar files
>>>>>>> is    working just fine.
>>>>>>> org.apache.commons.configuration.ConfigurationException: SAX
>>>>>>>   Exception caught
>>>>>>>  at      
>>>>>>> org.apache.commons.configuration.ConfigurationFactory.getConfiguration(
   [my own      
>>>>>>> code]
>>>>>>> Caused by: java.lang.NoSuchMethodException: No such accessible
>>>>>>>     method: addConfiguration() on object:      
>>>>>>> org.apache.commons.configuration.ConfigurationFactory$ConfigurationBuilder
>>>>>>> org.apache.commons.digester.Digester.parse(
>>>>>>>  at  [...]
>>>>>>> org.apache.commons.configuration.ConfigurationFactory.getConfiguration(
    ... 11      
>>>>>>> more
>>>>>>> Any ideas?  It still happens even if I switch versions of   
>>>>>>> digester  and config jar files, and when I tried replacing the
>>>>>>>  JVM.
>>>>>>> thanks
>>>>>>> Joe
>>>>>> Hm,
>>>>>> looks like jar hell. Which versions of configuration and digester
>>>>>> you use? Is it possible that jars with different version numbers
are on
>>>>>> your class path? Or that jars are in the lib/ext directory of your
>>>>> I know it looks like jar hell.  However, I've done this with     
>>>>> multiple versions of the digester and config jars including the   
>>>>>   latest and greatest (digest 1.8 and config 1.4).
>>>>> And in a slightly different environment/setup (embedded in a   
>>>>> JBoss  server), the jar files that I should be using (config 1.1  
>>>>>  and the  digester that's bundled with struts 1.2.9) have no   
>>>>> problem at all.   This only came about when trying to make a   
>>>>> standalone version of  the code to debug an SSL connectivity   
>>>>> issue.
>>>>> Joe
>>>> So does the application that causes the problem run on a JBoss or as a
>>>> plain Java application?
>>>> In the latter case, when you have full control over the class path,
>>>> this should really be unproblematic, shouldn't it?
>>>> In case of a server environment: Could it be a class loader issue, e.g.
>>>> a digester version in the server's lib directory could be used, which
>>>> does not see your application classes?
>>> The server environment is the one that works (it just has the SSL   
>>>  issues that I'm trying to isolate and debug).
>>> It's making it standalone that doesn't work.
>>> And I've been doing Java and arguing with classpaths since 1996 so  
>>>  I  think I'm pretty sure I'd already ruled the basics.  It should  
>>>  be  unproblematic which is why I'm posting it here.
>>> I mean, you really can't get much simpler than
>>> set JAVA_HOME=C:\jdk1.5.0_06
>>> set L=..\lib
>>> set CP=%L%\[my code .jar]
>>> set CP=%CP%;%L%\collections.jar
>>> set CP=%CP%;%L%\commons-logging.jar
>>> set CP=%CP%;.\commons-configuration-1.1.jar
>>> set CP=%CP%;.\commons-lang-2.1.jar
>>> set CP=%CP%;.\commons-digester.jar
>>> set CP=%CP%;.\commons-beanutils.jar
>>> set CP=%CP%;.\junit.jar
>>> set CP=%CP%;..\.
>>> %JAVA_HOME%\bin\java -classpath %CP% junit.awtui.TestRunner
>>> Yet i get this failure for every combination of digester +    
>>> configuration that I've tried.
>>>> Sorry, just guessing...
>>> no worries.
>> More wild guesses: * have you checked your $JAVA_HOME/jre/lib/ext   
>> directory? Maybe someone has placed a commons lib in there?
>> * have you checked $JAVA_HOME/jre/lib/security? Maybe someone has   
>> created a security policy file that is causing problems..
>> The class and method that are being reported as inaccessable have   
>> been in commons-configuration for a very long time, so it is   
>> unlikely that this problem is due to mismatched jar versions.
>> My guess is that there are multiple copies in the classpath (and   
>> two classes loaded via different classloaders are always   
>> incompatible). But it's only a guess, as we don't have much info   
>> about your setup.
>> You might try turning on logging for digester and seeing whether   
>> anything useful is output. Digester has extensive internal logging;  
>>  just enable the debug level for category   
>> "org.apache.commons.digester" using whatever logging lib you have   
>> in your app. Regards,
>> Simon
> One more thought: If you switch to a different version of
> configuration, does this have any effect on the stack trace? For
> instance, in configuration 1.5 (which is the latest release) the line
> in ConfigurationFactory that calls digester and causes the exception
> has moved somewhere in the 180s. So the line numbers in your stack
> trace should change.
> If this is not the case, you can be sure that your classes are loaded
> from somewhere else - not from the jars.
> Oliver
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message