wrapper.java.library.path.append_system_path
Kompatibel :3.1.0
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/Linux

Der Java Service Wrapper beinhaltet eine native Bibliothek als Komponente, und erfordert daher, dass der Speicherort der Bibliothek festgelegt wird, indem man ihren Speicherort der JVM unter Nutzung der java.library.path-Systemeigenschaft weitergibt.

Normalerweise, wenn Java gestartet wird und ein Bibliothekspfad nicht spezifiziert ist, dann nutzt die JVM standardmäßig den System PATH unter Windows und die LD_LIBRARY_PATH auf UNIX-Systemen, um alle nativen Bibliotheken, die von der Anwendung geladen wurden, ausfindig zu machen. Dies ist ähnlich, was mit der CLASSPATH-Umgebungsvariablen geschieht, wenn ein spezifischer Classpath beim Starten der JVM nicht spezifiziert wurde. Der Nutzen der CLASSPATH-Umgebungsvariablen ist aufgrund all der Konfliktprobleme, die entstehen können, wenn mehrere Java-Anwendungen auf der gleichen Maschine installiert sind, aus der Mode gekommen. Die gleichen Probleme gibt es ebenso bezüglich des Bibliothekspfads. Aber ein paar Anwendungen nutzen immer noch standardmäßig den System PATH oder LD_LIBRARY_PATH.

Im Allgemeinen ist es ratsam, bei Ihrem Anwendungseinsatz mögliche Probleme zu vermeiden, indem man behutsam-konservativ bezüglich dessen bleibt, welche Verzeichnisse in den Java-Bibliothekspfad hinzugefügt werden. Jedoch, wenn es notwendig ist, den kompletten Pfad zu durchsuchen, dann bewirkt diese Eigenschaft den Wrapper die Inhalte des SystemPATH oder des LD_LIBRARY_PATH zum Java-Bibliothekspfad hinzuzufügen, der genutzt, um die JVM zu starten. Es wird eher angefügt als vorangestellt, so dass Verzeichnissen, die für die Nutzung der wrapper.java.library.path.<n> Eigenschaften konfiguriert wurden, Priorität gegeben wird. Der Standardwert ist "FALSE".

Beispiel: 
wrapper.java.library.path.append_system_path=FALSE

NOTE

Einige native Bibliotheken verweisen auf andere dynamisch verbundene Bibliotheken(dynamically linked libraries, DLL). Java macht die anfängliche JNI-Bibliothek ausfindig, indem es den Java-Bibliothekspfad benutzt; aber untergeordnete Bibliotheken werden mittels der Standardvorgehensweise für die jeweilige Plattform geladen.

Unter Windows sieht das System erst in das Arbeitsverzeichnis (dem Speicherort der wrapper.exe), dann wird es in das Windows-System32 und das Windows-Verzeichnis sehen. Schließlich wird es die gesamte System PATH durchsuchen. Wenn beide DLLs sich in dem lib-Verzeichnis Ihrer Anwendung befinden, kann es notwendig sein, ihren Speicherort Ihrem Systemverzeichnis wie folgt hinzuzufügen. Die set.PATH ist für Windows und die set.LD_LIBRARY_PATH macht die Konfigurationsdatei plattformübergreifend, so dass diese auch auf UNIX-Systemen läuft. Mac OSX 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%

Beachten Sie, dass das Speichern der untergeordneten Bibliothek in PATH statt in das aktuelle Arbeitsverzeichnis das Risiko birgt, dass eine alte Version dieser Bibliotheksdatei zuerst im Windows System32 Verzeichnis gefunden werden könnte, wenn es dort vorher durch eine andere Anwendung installiert worden wäre. Dies ist aufgrund der Reihenfolge, in der das System nach der Datei sucht, der Fall.

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

Verweis: Bibliothek
  • wrapper.java.library.path.<n> (2.2.9)

    Spezifiziert eine Liste von Verzeichnissen, die alle native interne Bibliotheken des Wrappers und der Java-Anwendung enthalten.

  • wrapper.java.library.path.append_system_path (3.1.0)

    Fügt den Inhalt des System-PATH den Java-Bibliotheken-Pfad hinzu.

  • wrapper.native_library (3.1.0)

    Legt den Basisnamen der nativen Bibliothek des Wrappers fest.

  • wrapper.working.dir (3.1.0)

    Legt den Pfad auf das Arbeitsverzeichnis fest.