Java web application cannot use native library (.so)

Technical Summary: I am developing a Java web service deployed on GlassFish v3, running on CentOS 5.

My web service uses the functionality provided by my own library (.so). The native library works fine, but I was not very lucky in setting up the environment correctly to load my own library, but I was not affected by the redeployment of web applications without restarting the application server.

What i have done so far:

First I loaded the library (static {System.load (path / to / libabc.so)};) into the web service code, all the paths are set correctly, and it works fine until I deploy the application and it complains that the library is loading another ClassLoader. I found out that native libraries load only once.

To try to solve this problem, I removed the library loading code from the web application, created the Singleton class, wrapped it in the Lifecyle module, expanded it into the GlassFish share folder, and then configured GlassFish to start the shell when it starts. The idea is that now all web applications will be able to refer to it, since it is not tied to one particular web application and is loaded by ClassLoader above in the hierarchy.

When GlassFish starts, the source library loads successfully (linux> lsof | grep libabc.so). However, the web service code does not work with UnsatisfiedLinkError when executing a native method in my web service Java code. It seems to me that the code in the web application does not have access to the library loaded at startup.

Can someone tell me what I am doing wrong?

Thanks in advance.

+6
glassfish jni
source share
2 answers

I can’t say much about the “Lifecyle module” (I don’t know if they should be “visible” for applications deployed in GlassFish), but ...

I would put a JNI library and a class that calls System.loadLibrary(String) , such as singleton, outside of webapp and deploy this code to domain/lib or domain/lib/applibs (see Layout of a file in V3 and this thread for more information about them).

This should make the code visible to your application, and your application is resilient to redistribution.

+4
source share

solved!

Finally, I gathered the pieces.

the missing part The JNI library (for example, jni_wrapper_for_libabc.jar ) was jni_wrapper_for_libabc.jar to the GF shared folder domains/domain1/lib , and it worked. The native lib is loaded by the Singleton class in the Lifecycle Module, which is called when GF starts.

Thanks, Pascal, a great helper!

Greetings

+2
source share

All Articles