6 Replies Latest reply on May 6, 2015 9:19 PM by David Lloyd

    Wildfly Native Libraries

    Larry DeVries Newbie

      I am using Wildfly 8.1.0 on a Linux x84_64 environment (CentOS) and have an application that runs some native code via JNI.  According to what I find in this article, https://docs.jboss.org/author/display/MODULES/Native+Libraries

      I should be able to place the native .so(s) in a module directory of the structure .../main/lib/linux-x86_64 and have Wildfly add it to the search path instead of having to export LD_LIBRARY_PATH to the native modules.  Currently, the code works just fine as long as I export the path.  It does not find the native libraries unless I do the export.  I would like to have Wildfly just handle it based on the environment we are running in.  I have tried various setups of the module.xml with no luck.


      Can anyone provide some further direction on what I might be missing ?


      Here is my module.xml

      <?xml version="1.0" encoding="UTF-8"?>

      <module xmlns="urn:jboss:module:1.0" name="com.mypackage">


             <resource-root path="lib"/>

             <resource-root path="myjar1.jar"/>

              <resource-root path="myjar2.jar"/>



            <module name="javax.api"/>



        • 1. Re: Wildfly Native Libraries
          Tomaz Cerar Master

          how and from which code are you loading native library?

          is that code part of the same module?

          • 2. Re: Wildfly Native Libraries
            Larry DeVries Newbie

            Yes, the code that uses the native library is part of the same module.  For example, using from my original question, the classes in myjar1.jar are doing JNI calls to the native module in the underlying lib/linux_x86_64 directory.


            So, the directory structure looks like this:








                           ------ libNativeCode.so


            The classes in myjar1.jar are doing the JNI calls to libNativeCode.so


            However, right now the only way I can get this to work is to export the LD_LIBRARY_PATH to the libNativeCode.so.  From what I read, this is not supposed to be necessary.

            • 3. Re: Wildfly Native Libraries
              David Lloyd Master

              I suspect the problem might be that you have added an explicit "<resource-root path="lib"/>" to your module definition.  This is not necessary and could possibly be confusing the resource loader somehow.

              • 4. Re: Wildfly Native Libraries
                Larry DeVries Newbie

                I have tried about every combination of parms in the module.xml that I could find, all to no avail.  I tried the resource without a lib reference at all, I tried with just a period, with nothing in the dependencies.  I can't seem to get anything to work.


                Is it possible that there is some kind of naming convention that must be adhered to for it to work ?  What I mean is if the jar is named myjar1.jar, does the native library have to be named libmyjar1.so ???  I sure hope this is not the case because we have one jar and two .so's.


                Any recommendation are appreciated.  Thanks.

                • 5. Re: Wildfly Native Libraries
                  Tomaz Cerar Master

                  try enabling trace logging for "org.jboss.modules" category

                  it will help you debug this.

                  • 6. Re: Wildfly Native Libraries
                    David Lloyd Master

                    No, there is no special naming convention.  At this point random combinations are probably not useful though; some methodical troubleshooting is required.  The first thing is to be certain that it is the code in the module which is calling System.loadLibrary() or System.load(), as these methods are sensitive to the class loader of the calling class. Secondly, the only resource roots you need in the descriptor are the two JARs; adding in "." or "lib" may be actively preventative in terms of getting the library to load.  So this should be our troubleshooting baseline.


                    Native library name mapping and loading is not part of the trace logging, so this will not be a useful thing to do.  One possibility is to use the Linux strace utility to identify exact path names being opened.  The last point I want to emphasize is that paths are case-sensitive, and that you should double-check that you are indeed running on a 64-bit JVM.