Java library path to use. You should have a series of properties
listing up the various library path elements to use when launching the application.
The library path is used to specify a list of directories
in which to look for any native (JNI) libraries used by the application.
You must place the library file
(Windows: wrapper.dll, Linux/UNIX: libWrapper.so)
in one of the directories specified.
Each element has a property name which starts with
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
property can optionally be set to allow gaps in the sequence.
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
property before doing so.
Library Path entried containing spaces:
The Wrapper will correctly handle path elements which contain spaces.
This is done later by the Wrapper 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.
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.
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.
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:
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.
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 sytems 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 environment variables can then we set up as follows.