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.