(FIX) GDAL extension not working with GeoServer’s Windows service wrapper
Today, we have investigated the issue reported by several users on the GeoServer’s mailing list about being unable to get the GDAL-ImageI/O-Ext extension to work when GeoServer runs as a service on Windows.
Deploying the GDAL ImageI/O-Ext native libraries in a location referred by the PATH environment variable (like, as an instance, your JDK/bin folder) allows GeoServer to successfully recognize them when invoked via the start.bat script. However, this does not seem to work when running GeoServer as a service on Windows. As a result, during the service startup, GeoServer log reports this worrysome message:
WARNING: Native library load failed.java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path
Taking a look at the wrapper.conf configuration file available inside the GeoServer installation (at wrapper/wrapper.conf), we can find this useful entry:
# Java Library Path (location of Wrapper.DLL or libwrapper.so)
To solve the issue, you have 2 possible ways:
- move the native DLLs on the referred path (wrapper/lib)
- add a wrapper.java.library.path.2=path/where/you/deployed/nativelibs entry just after the wrapper.java.library.path1=wrapper/lib line.
Note that latest GDAL version (from 1.9.x series) depend on specific MSVC libraries.
Therefore, you may also need to add the following line to the wrapper/wrapper.conf:
By this way, the system will look for dynamic libraries on wrapper/lib as first place, then on %PATH% in case some dependency isn’t on wrapper/lib.
Restarting the service, you should now see the GDAL ImageI/O-Ext plugins available when you try to create a new store, as shown in the image below. Notice that we are here assuming that you have properly configured the various environment variables as suggested in this link.