org.geotools.data.DataSourceException

运行geoserver，出现异常：

Caused by: org.geotools.data.DataSourceException: No reader avalaible for this source
        at org.geotools.gce.image.WorldImageReader.getHRInfo(WorldImageReader.java:293)
        at org.geotools.gce.image.WorldImageReader.<init>(WorldImageReader.java。

上网搜了下，牛人给出解决方案(http://geo-solutions.blogspot.com/2010/05/fix-geotools-and-geoserver-not-able-to.html)，但是被墙了，所以在这记录下：
The Problem


Lately some GeoTools and GeoServer users reported issues related to
GeoTools raster plugins not being properly loaded in Tomcat 6.0.24 and
above.

Typical scenario is as follows: Geoserver deployed in Tomcat 6.0.26
along with the GDAL ImageIO-Ext extensions. The available GDAL formats
properly appear in the Store user interface but, when trying to
configure a new coverage, an error is reported and the logs shows the
following message

Caused by: java.lang.IllegalArgumentException: Incorrect input type!
at javax.imageio.ImageReader.setInput(ImageReader.java:290)
at
it.geosolutions.imageio.gdalframework.GDALImageReader.setInput(GDALImageReader.java:838)




The cause


Behind the scenes this is what is happening:

• In latest Tomcat releases a huge amount of work
  has been put in in order to solve some memory leaks that were causing
  Out Of Memory (OOM) errors during web application reload.
• Specifically the problems seems to be the JreLeakPreventionListener
  which interferes badly with the ImageIO IIORegistry where the low level raster plugins are registered. The JreLeakPreventionListener
  basically deregister
  them all during web application startup to prevent memory leaks.

The solution


Providing a general solution is not dead easy, since this is a bug at
theJDK/JRE level (there is where the IIORegistry resides). However, two
different workarounds can be implemented, with different impact on the
application lifecycle:

1. Set the JreMemoryLeakPreventionListener
   attribute called appContextProtection
   to “false” in Tomcat’s server.xml
   configuration file (found under the conf
   directory of the Tomcat installation). Notice that this will leave
   memory leaks around in case you re-deploy GeoServer multiple times which
   requires a restart of Tomcat itself. This is not a problem in case you
   don’t plan to redeploy GeoServer frequently.
2. You can move all the JAI and ImageIO jars from GeoServer WEB-INF/lib
   directory to Tomcat’s shared/lib folder in order to share them between
   all the web context in tomcat. This will not leave any memory leak
   around but in case you have other applications deployed inside the same
   Tomcat instance which contains JAI or ImageIO libraries, you need to
   remove them as well or you might get class-loading conflicts.

Ciao a tutti,
Simone.

转载自：https://blog.csdn.net/chengcyh/article/details/84181133