IBM Application Runtimes Come for answers. Stay for best practices. All we’re missing is you. Join / Log in Ask a question
My application relies on native libraries (C++) and we use LD_LIBRARY_PATH in Tomcat, which works fine. However, if we use the same in server.env or exporting on the console before server startup, it gives the below message in logs.
0000034 id=00000000 com.ibm.ws.webcontainer.filter.FilterInstanceWrapper E service SRVE8109W: Uncaught exception thrown by filter filterChainProxy: java.lang.UnsatisfiedLinkError: Native Library /home/data/webapp1/bin/libcrap.so already loaded in another classloader at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:208) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:181) at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:322) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:294) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:1801) at java.base/java.lang.System.loadLibrary(System.java:754)
We did try by adding library in server.xml , which gave the message of "can't load libcrap.so"
Any suggestions on unblocking the situation?
Hi, Anoop. Two quick questions:1) What version of Java are you using, and is it the same as you're using on Tomcat?
2) Does the code that instantiates the native library exist in more than one application (so loadLibrary is called from separate application class loaders)?
If you have that code in multiple apps, one solution might be to move the code that calls System.loadLibrary() from the applications to a shared library, and associate the library with the applications using a commonLibraryRef. The commonLibraryRef creates a separate class loader for the shared library that the application class loaders would delegate to, and since the library would only be defined from that shared library class loader, the "already loaded in another classloader" situation would not occur.