关于geoServer启动的错误

最新推荐文章于 2024-07-24 11:13:53 发布

Virgo_S

最新推荐文章于 2024-07-24 11:13:53 发布

阅读量1.8k

点赞数

分类专栏：开源GIS 文章标签： Java EXT Web UP .net

本文链接：https://blog.csdn.net/Virgo_S/article/details/83363747

版权

开源GIS 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

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:
[list]
[*]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.
JAI下载地址:
[url]https://jai.dev.java.net/binary-builds.html[/url]
[*]the web container has old JAI jars in the shared libraries, that are usually put in the classpath before the application ones.
[/list]
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).
通常有两个原因会导致这个情况：
1.另外的软件可能把JAI包安装到jre/lib/ext下面，该包会覆盖其它其它所有应用程序的包。
2.Web容器共享库里面有个老版本的JAI库，通常会放到Classpath里面去。
第一种情况可以从JAI网站上去下载最新的稳定版来覆盖旧版本即可。
第二种情况，从网站上下载纯java版本的jai安装包，来覆盖共享库里的。或者找寻一种方法使得web容器加载jar包比共享库的早。