wrapper.java.library.path.<n>
Kompatibel :2.2.9
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/Linux
? Please check the English version for a more recent version of this text.

Java Bibliothekspfad. Sie sollten eine Reihe von Eigenschaften haben, die die verschiedenen Bibliothekspfad-Elemente auflisten, die genutzt werden, wenn die Anwendung gestartet wird.

Der Bibliothekspfad wird genutzt, um eine Liste von Verzeichnissen zu spezifizieren, in denen man nach jedwede systemeigene (JNI) Bibliotheken, die von einer Anwendung genutzt wird, suchen kann. Sie müssen die Bibliotheksdatei (Windows: wrapper.dll, Linux/UNIX: libwrapper.so) in einer der spezifizierten Verzeichnisse platzieren.

<n> Komponente:

Jedes Element hat einen Eigenschaftennamen, der mit wrapper.java.library.path. startet und die "<n>" Komnponente des Eigenschaftennamens ist eine Integer-Zahl, die von "1" hinaufzählt. Standardmäßig kann es keine fehlende Zahlen geben. Die wrapper.ignore_sequence_gaps Eigenschaft kann optional gesetzt werden, um Lücken in einer Zeichenfolge zu erlauben.

Beispiel: 
wrapper.java.library.path.1=../lib

Es ist auch möglich, das Standard-Java-Verhalten zu erhalten, indem angefordert wird, dass der Systempfad ans Ende des vom Wrapper erzeugten Java-Bibliothekspfads angehängt wird. Bitte lesen Sie bitte die Dokumentation, die zu der wrapper.java.library.path.append_system_path Eigenschaft gehört, bevor Sie dies so tun.

NOTE

Eingegebener Bibliothekspfad enthält Leerstellen:

Der Wrapper kann korrekt mit Pfadelementen umgehen, die Leerstellen enthalten. Dies wird seitens des Wrappers in der Nachfolge durch Einschließen des zuletzt erzeugten Bibliothekspfad in Anführungszeichen erledigt. Die Eigenschaftenwerte von einzelnen Bibliothekspfadelementen sollten niemals mittels Anführungszeichen definiert werden, auch wenn sie Leerzeichen aufweisen würden.

NOTE

Einige systeminterne Bibliotheke verweisen auf andere dynamisch verbundene Bibliotheken (DLLs, dynamically linked libraries). Java findet die Start JNI Bibliothek durch Nutzung des Java-Bibliothekspfad, Aber die untergeordneten Bibliotheken werden durch Nutzung der Standardvorgehensweise geladen.

Unter Windows sieht das System erst in das Arbeitsverzeichnis (Der Ort 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, mag es notwendig sein, diese Ort-/Pfadangabe 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 Platzieren der untergeordneten Bibliothek eher in PATH als in das gegenwärtige 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 wurde bei der Arbeit mit SAPs JCO Bibliotheken angetroffen, wenn bereits andere SAP-Anwendungen auf dem System installiert sind.

Plattformspezifische systemeigene Bibliotheken

Der Wrapper stellt eine Möglichkeit bereit, es einfach zu machen, binäre Distributionen zu erstellen, die auf alle Plattformen laufen, selbst im Fall, wenn die Anwendung systemeigene Bibliotheken nutzt.

Im Fall der eigenen Bibliothek des Wrappers, ist der Wrapper intelligent, sein eigene Komponente zu finden. Die Bibliothek kann so benannt werden, dass diese den gegenwärtigen Betriebssystemnamen, Plattformnamen und Bittiefe enthält. Beispiele sind: wrapper-windows-x86-32.dll und libwrapper-linux-x86-32.so.

Die meisten Bibliotheken unterstützen dieses Feature allerdings nicht und erwarten, dass ihre eigene Bibliotheken auf die gleiche Weise für alle Plattformen benannt werden. Dies führt gewöhnlich dazu, dass plattformspezifische Distributionen einer Anwendung herausggeben werden müssen. Durch Definieren des Bibliothekspfads wie folgt, verweist der Wrapper dynamisch während seiner Ausführung auf das korrekte plattformspezifische Verzeichnis und ermöglicht es so, alle unterstützten Plattformen in einer einzelnen Distribution des Wrappers zu beinhalten.

Beispiel: 
wrapper.java.library.path.1=../lib
wrapper.java.library.path.2=../lib/native/%WRAPPER_OS%-%WRAPPER_ARCH%-%WRAPPER_BITS%

Welches sich wie folgt aufteilt:

Windows: 
wrapper.java.library.path.1=../lib
wrapper.java.library.path.2=../lib/native/windows-x86-32
Linux: 
wrapper.java.library.path.1=../lib
wrapper.java.library.path.2=../lib/native/linux-x86-32
Solaris: 
wrapper.java.library.path.1=../lib
wrapper.java.library.path.2=../lib/native/solaris-sparc-32

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.