commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <simon.kitch...@chello.at>
Subject Re: [configuration] Config + Digester NoSuchMethodException
Date Thu, 01 Jan 1970 00:00:00 GMT
---- jws@javaclientcookbook.net schrieb:
> Quoting Oliver Heger <oliver.heger@oliver-heger.de>:
> 
> > jws@javaclientcookbook.net schrieb:
> >> Quoting Oliver Heger <oliver.heger@oliver-heger.de>:
> >>
> >>> jws@javaclientcookbook.net 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(ConfigurationFactory.java:169)
   [my own    
> >>>> code]
> >>>> Caused by: java.lang.NoSuchMethodException: No such accessible    
> >>>> method: addConfiguration() on object:    
> >>>> org.apache.commons.configuration.ConfigurationFactory$ConfigurationBuilder
  at    
> >>>> org.apache.commons.digester.Digester.parse(Digester.java:1591)
> >>>>   at  [...]
> >>>> org.apache.commons.configuration.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:163)
    ... 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 do
> >>> 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 JRE?
> >>
> >> 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 my.test.case
> 
> 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

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


Mime
View raw message