Remove load library calls #15
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 the 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. 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). Note: There are several other calls to System.loadLibrary(), but they are made from the ImageIO-Ext code, and then should be fixed there.
- Need to use my specific version of imageio-ext (which suppresses the uneeded System.loadLibrary calls) - Adding the local maven repository
|
Sorry for the noise, wrong repository. |
|
For the record, the good one is geotools#443 |
nstires-boundless
pushed a commit
that referenced
this pull request
Apr 28, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The main idea behind this PR is to avoid calls to System.loadLibrary()
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-javainstalled, it means having a symlink from${CATALINA_HOME}/lib/gdal.jarpointing to/usr/share/java/gdal.jar).