cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <>
Subject Re: Double occurence of class DefaultConfiguration in builded trunk.
Date Sat, 20 May 2006 15:06:10 GMT
(This topic was started on the users list)

Ronald Borman wrote:
> I wanted to see the new developments in Cocoon 2.2, so today I
> checked out the trunk (revision 407982) with Subversion and built it
> with Maven. After getting a succes build message, I copied the the
> file cocoon-webapp.war to the webapps directory of my Apache Tomcat
> 5.0.28 installation and started the service.
> I pointed my browser to http://localhost:8080/cocoon-webapps. But
> instead of the welcome page I got a HTTP 500 error message containing
> a java.lang.NoClassDefFoundError exception, without a class name. The
> message in the logs was more clear, it contained the following line:
> java.lang.NoSuchMethodError:
> org.apache.avalon.framework.configuration.DefaultConfiguration.<init>(Ljava/lang/String;)V
> By checking the cocoon-webapp\lib directory I found that this class
> occurred in two archives, avalon-framework-4.0.jar and
> avalon-framework-impl-4.3.jar.
> After deleting the first file and restarting Tomcat, the right class
> file was loaded and the problem dissappeared.
> As I found no mention of this in de mail lists, is it a bug or did I
> forgot something during the build process?
> Ronald Borman

I ran into this same issue while integrating Cocoon 2.1.9 into a Maven 
build for my own project.  The problem was that Cocoon itself has a 
dependency on avalon-framework 4.3, while one of its other dependencies 
(fop 0.20.5) has a transient dependency on avalon-framework 4.0.  You 
end up getting both JARs in the resulting webapp, and your servlet 
container apparently chooses one at random to use (Jetty chooses 4.3, 
Tomcat chooses 4.0 hence the error).

The solution for me was to specifically exclude the avalon-framework 
transient dependency for fop:


It appears the pom.xml for the cocoon-fop-impl block does not have this 
exclusion; it should probably be added.


View raw message