My application uses a C module called "DRI". We are migrating form websphere 6.1 to tomcat6 under linux Redhat6 and we are experiencing difficulties with tomcat to load the C module.
This is how we load the library:
The location of the library is : /logiciels/tomcat/profiles/WRK00_D02/lib/libDRI.so
We have defined java.library.path in the parameters for the jvm. This is the list of parameters for the JVM when we start tomcat:
We always get this error. :
Do we need any other configuration in Tomcat to load the C library DRI.so?
It seems that in Websphere we can load libraries dynamically from the file system, but it is not possible in Tomcat. Am I right? How can I load the library in tomcat outside and use it in the application?
Any help will be much appreciated. Thank you in advance
As you said I had a problem with the variable LD_LIBRARY_PATH. I have 5 tomcat profiles (workers?). Different versions of the C module could be deployed in $CATALINA_BASE/lib (not CATALINA_HOME). I start every tomcat with the interface Tomcat Manager, so I can't define LD_LIBRARY_PATH in the .bash_profile or .bash_rc of an user account, so I made the export of LD_LIBRARY_PATH in catalina.sh with the value value $CATALINA_BASE/lib. This trick worked out when I wrote the full path to the lib folder of just one worker.
Using $CATALINA_BASE would work out with just one tomcat, but when I use at least 2, and the second doesn't have the C module in the lib folder, I get the UnsatisfiedLinkError.
Where could I define the variable LD_LIBRARY_PATH with the full path (not $CATALINA_BASE) for every worker? I tried using java.library.path in the JAVA_OPTS of the catalina.sh, but I need to specify multiple paths and it didn't work (I trid with : and ; and defining several times -Djava.library.path=...).
Any ideas would be much appreciated. Thank you in advance
The generally-accepted usage in Linux, as in Windows, is that loadable libraries (DLLs) are Shared Objects. Linux allows multiple versions of .so files, where the version number is part of the name, but expects that only one instance of any given version will exist.
To actually tie a specific library file to a specific Tomcat would require either fronting the tomcat scripts with a load-library export or modifying the catalina.sh script itself. Tomcat adheres to the "write-once/run-anywhere" principle and that means that it has made no effort to support external OS quirks.