I think it was caused by gvSIG after reading the following ciation. And I have successfully run geoserver in tomcat before I installed gvSIG and the tomcat is clearly works well.
-------------------------------------------------- Citation --------------------------------------------
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 /jre/lib/ext. In this position the jars override the classpath of whatever application is running on the virtual machine.
JAI下载地址:
https://jai.dev.java.net/binary-builds.html- 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).