WebSphere Application Server & Liberty

 View Only
Expand all | Collapse all

Loading Native library in open liberty

  • 1.  Loading Native library in open liberty

    Posted Fri November 17, 2023 01:48 PM

    Hello,

    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?



    ------------------------------
    Anoop KR
    ------------------------------


  • 2.  RE: Loading Native library in open liberty

    Posted Fri November 17, 2023 04:07 PM

    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.



    ------------------------------
    Jarid Kvale
    ------------------------------