geotools/geotools — pull request #443 by pmauduit (2014-04-29 17:46:37+00:00)
Title: Remove load library calls

The main idea behind this PR is to avoid calls to System.loadLibrary()

(This one was by mistake originally opened onto the fork from boundlessgeo, I apologize for the noise)

In some special but common cases, several different calls to System.loadLibrary using the same lib name as argument can lead to undesired behaviours (Raising an exception "java.lang.UnsatisfiedLinkError: library already loaded in classloader").

A typical case of specific classloading is when using the library in several different webapps nested into the same servlet container (tomcat). Even if the library is actually correctly configured and fully available, GeoTools reports it as unavailable (due to the exception thrown).

A PoC which tends to prove this issue has been provided here: https://github.com/pmauduit/jai-imageio-sample/tree/master/jai-imageio-gdal-sample-webapp

In this PoC webapp, a first approach makes use of the JNI GDAL/OGR bindings directly, another one is then attempted using GeoTools (class JniOGRDataStoreFactory). The first one (once tomcat is correctly configured) shows that the library is fully available, though it is reported as unavailable by GeoTools. Duplicating the webapp (so that we can have several contexts trying to use the same native lib) shows that the second one is also unable to access the features that GDAL provides.

The litterature I could read on the topic (classloading in Java seems to be one of the big mistery around the language, though) explains that we should avoid packaging webapps with jar files making use of the System.loadLibrary calls. These have to be shared: the jar file should be made available in the higher-level classloader (for tomcat under debian-like distros with libgdal-java installed, it means having a symlink from ${CATALINA_HOME}/lib/gdal.jar pointing to /usr/share/java/gdal.jar).