wrapper.java.library.path.append_system_path
Compatibilidad :3.1.0
Ediciones :Edición ProfesionaEdición EstándarEdición de la Comunidad
Plataformas :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/OSIBM z/Linux

The Java Service Wrapper includes a native library component, and thus requires that the location of that library be specified by passing its location to the JVM using the java.library.path system property.

Normally when Java is launched and a library path is not specified, the JVM will default to using the system PATH on Windows and the LD_LIBRARY_PATH on UNIX systems to locate any native libraries loaded by the application. This is akin to what happens with the CLASSPATH environment variable when a specific classpath is not specified when launching the JVM. The use of the CLASSPATH environment variable has fallen out of style because of all the conflict problems which can arise when multiple Java applications are installed on the same machine. The same issues are all there with the library path as well. But some applications still make use of the system PATH or LD_LIBRARY_PATH by default.

In general, it is advised that you avoid potential problems when your application is deployed by being conservative about which directories will be included in the Java library path. However if there is a need to search the entire PATH, then this property will cause the Wrapper to append the contents of the system PATH or LD_LIBRARY_PATH to the Java library path used to launch the JVM. It is appended rather than prepended so that directories configured using the wrapper.java.library.path.<n> properties will be given priority. The default value is "FALSE".

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

NOTA

Some native libraries reference other dynamically linked libraries. Java will locate the initial JNI library using the Java library path, but the secondary libraries are loaded using the default mechanism for the platform.

On Windows, the system will first look in the current working directory (The location of the wrapper.exe), then it will look in the Windows system32 directory and the Windows directory. Finally, it will search the entire system PATH. If both DLLs are located in your application's lib directory, it may be necessary to add its location to your system path as follows. The set.PATH is for Windows and the set.LD_LIBRARY_PATH makes the configuration file cross platform so it works on UNIX systems as well. Mac OSX also makes use of the 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%

Note that placing the secondary library on the PATH rather than in the current working directory has a risk that an old version of the library could be encountered first in the Windows system32 directory if it was installed by another application. This is due to the order in which the system looks for the file.

This problem has been seen when working with SAP's JCO libraries if other SAP applications are also installed on the system.

Referencia: Librería
  • wrapper.java.library.path.<n> (2.2.9)

    Especifica una lista de directorios que contiene bibliotecas nativas utilizadas por el Wrapper o la aplicación Java.

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

    Agrega el contenido del PATH del sistema a la ruta de la biblioteca Java.

  • wrapper.native_library (3.1.0)

    Establece el nombre de base de la biblioteca nativa de Wrapper.

  • wrapper.working.dir (3.1.0)

    Establece la ruta al directorio de trabajo.