wrapper.java.library.path.<n>
Compatibility :2.2.9
Editions :Professional EditionStandard EditionCommunity Edition
Platforms :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/Linux

These properties are used to specify a list of directories in which to look for any native (JNI) libraries used by the application. You must place the Wrapper native library (Windows: wrapper.dll, Linux/UNIX: libwrapper.so) in one of the directories specified.

<n> component:

Each element has a property name that starts with wrapper.java.library.path. and the "<n>" component of the property name is an integer number counting up from "1". By default, there can be no missing numbers. The wrapper.ignore_sequence_gaps property can optionally be set to allow gaps in the sequence.

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

It is also possible to get the default Java behavior by requesting that the system path be appended to the end of the Java library path generated by the Wrapper. Please read the documentation, associated with the wrapper.java.library.path.append_system_path property before doing so.

NOTE

Library Path entries containing spaces:

The Wrapper will correctly handle path elements containing spaces. This is done by enclosing the final generated library path in quotes. Individual library path element property values should never be defined containing quotes, even if they contain spaces.

NOTE

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.

Please use the wrapper.system.library.path.<n> properties to configure paths were secondary libraries are located.

Platform-specific native libraries

The Wrapper also provides a facility to make it easy to create binary distributions that run on any platform, even if the application makes use of native libraries.

In the case of the Wrapper's native library, the Wrapper is intelligent about the way it locates its native component. The library can be named in such a way that it contains the current OS name, platform name, and bit depth. Examples are: wrapper-windows-x86-32.dll and libwrapper-linux-x86-32.so.

Most libraries do not support this kind of feature, however, and expect their native libraries to be named the same for all platforms. This usually results in having to release platform specific distributions of an application. By defining the library path as follows, however, the Wrapper will dynamically reference the correct platform specific directory at run time, making it possible to include all supported platforms in a single distribution of Wrapper.

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

Which resolves to the following:

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

NOTE

As above, if the native libraries need to load their own external libraries, you need setup the paths correctly as well. If those files are installed on the system externally, then the above method will work. But if you want to distribute them with your application, then place them in the platform specific directories with the other native libraries. The wrapper.system.library.path.<n> properties can then be set up as follows. 

wrapper.system.library.path.1=../lib
wrapper.system.library.path.2=../lib/native/%WRAPPER_OS%-%WRAPPER_ARCH%-%WRAPPER_BITS%

Reference: Library