Praxistipp: Wie lässt sich der Bibliothekspfad für JNI-abhängige Bibliotheken konfigurieren?

Kompatibel :	2.2.9
Editionen :
Betriebssysteme :

Java lädt native Bibiliotheken (JNI), indem der Pfad gesucht wird, der die java.library.path.Systemeigenschaft definiert. Der Java Service Wrapper macht es sehr einfach, diesen Pfad auf eine plattformübergreifende Art zu konfigurieren, indem die wrapper.java.library.path.<n>-Eigenschaften genutzt werden.

Das folgende Beispiel richtet einen Bibliothekspfad ein, der nach JNI-Bibliotheken in den ../lib/ and ../lib2/-Verzeichnissen sucht:

wrapper.java.library.path.1=../lib/
wrapper.java.library.path.1=../lib2/

Dies ist für die meisten JNI-Bibliotheken ausreichend, jedoch einige Bibliotheken für sich selbst machen Gebrauch von anderen Dynamic Link Bibliotheken. Java kann die primäre JNI-Bibliothek durch Nutzung des Java Bibliothek-Pfads finden, aber die zweitrangigen Bibliotheken werden durch den Standardmechanismus für die Plattform geladen.

Unter Windows sieht das System zuerst ins aktuelle Arbeitsverzeichnis (Der Ort der wrapper.exe-Datei), dann sieht es in das Windows-System32-Verzeichnis und das Windows-Verzeichnis. Schließlich wird es im gesamten System PATH suchen. Wenn sich beide DLLs in dem lib-Verzeichnis Ihrer Anwendung befinden, kann es notwendig sein, diesen Ort Ihrem System-Pfad wie folgt hinzufügen. set.PATH ist für Windows und set.LD_LIBRARY_PATH stellt die plattformübergreifende Konfigurationsdatei dar, die auch unter UNIX läuft. macOS nutzt auch die set.DYLD_LIBRARY_PATH-Variable.

set.PATH=..%WRAPPER_FILE_SEPARATOR%lib%WRAPPER_PATH_SEPARATOR%%PATH%
set.LD_LIBRARY_PATH=..%WRAPPER_FILE_SEPARATOR%lib%WRAPPER_PATH_SEPARATOR%%LD_LIBRARY_PATH%
set.DYLD_LIBRARY_PATH=..%WRAPPER_FILE_SEPARATOR%lib%WRAPPER_PATH_SEPARATOR%%DYLD_LIBRARY_PATH%

Bitte beachten Sie, dass es ein Risiko sein kann, dass zuerst durch eine andere Anwendungsinstallation eine ältere Version der Bibliothek im Verzeichnis Windows system32 gefunden werden könnte, wenn die sekundäre Bibliothek statt auf PATH in das aktuelle Arbeitsverzeichnis untergebracht wäre. Dies ist aufgrund der Reihenfolge, in der das System nach der Datei sucht, der Fall.

Dieses Problem wurde bei der Arbeit mit SAPs JCO-Bibliotheken festgestellt, wenn andere SAP-Anwendungen auch auf dem System installiert sind.

Bitte sehen Sie in der Dokumentation für die wrapper.java.library.path.<n> Eigenschaft bezüglich mehr Informationen.