Some users reported this error during GeoServer startup:

org.springframework.beans.FatalBeanException: Could not instantiate class
[org.vfny.geoserver.global.GeoServer]; constructor threw exception; nested
exception is java.lang.NoSuchFieldError: KEY_CACHED_TILE_RECYCLING_ENABLED
org.springframework.beans.FatalBeanException: Could not instantiate class
[org.vfny.geoserver.global.GeoServer]; constructor threw exception; nested
exception is java.lang.NoSuchFieldError: KEY_CACHED_TILE_RECYCLING_ENABLED
java.lang.NoSuchFieldError: KEY_CACHED_TILE_RECYCLING_ENABLED
	at org.vfny.geoserver.global.GeoServer.initJAI(GeoServer.java:719)
	at org.vfny.geoserver.global.GeoServer.load(GeoServer.java:494)
	at org.vfny.geoserver.global.GeoServer.<init>(GeoServer.java:129)

This happens because there are two conflicting JAI modules around, and with different versions. GeoServer uses and depends on JAI 1.1.2, whilst the JAI that ends up in the classpath in the above example is most probably 1.1 or older.

This can happen for one of two reasons:

• an external application (may be gvSig, Jump or some other application using JAI) have installed in the main Java runtime the JAI jars in <yourJdk>/jre/lib/ext. In this position the jars override the classpath of whatever application is running on the virtual machine.
• the web container has old JAI jars in the shared libraries, that are usually put in the classpath before the application ones.

In the first case, you can solve the problem by grabbing the JAI installers from the jai main site, lastest stable version, and run it to overwrite the old JAI version.
In the second case, download the pure java version of JAI from the same site and overwrite the jars in the shared libraries, or alternatively find a way to make your web container load the application jars before the shared lib ones (how to do this, if possible at all, is web container dependent, consult your container documentation).