HowTo: How to configure library path for JNI dependent libraries
Compatibility :2.2.9
Editions :Professional EditionStandard EditionCommunity Edition
Platforms :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/OSIBM z/Linux

Java loads native libraries (JNI) by searching the path defined with the java.library.path. system property. The Java Service Wrapper makes it very easy to configure this path in a platform-independent way by making use of the wrapper.java.library.path.<n> properties.

The following example will set up a library path that will search for JNI libraries in the ../lib/ and ../lib2/ directories: 

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

This is sufficient for most JNI libraries. However, some libraries themselves make use of 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 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.

Please see the documentation for the wrapper.java.library.path.<n> property for more information.