Using the Java native library on application servers

The Java native library (JNL) is a JAR archive containing JNI code and objects that the operating system can load as shared libraries. This allows calling functions implemented by platform-dependent methods from a Java application. Ways to create a JNL is the subject of a separate large article, so we believe that you already have JNL and you want to use it in your application. On the features of the use of JNL in applications running the application server, and this article will be.

Using JNL has the following negative effects:

• JNL code runs outside of the Java machine, which can lead to security issues;
• JNL itself, most likely, has a limited number of supported platforms (the combination of "operating system" - "processor"). Accordingly, an attempt to launch an application using JNL on a platform that is not supported by JNL will fail.

However, in some cases it is impossible to do without JNL. Examples include:

• the need to directly use the operating system API from a Java application (for example, to implement work with serial I / O ports);
• the need to implement heavy algorithms (such as media transcoding).

Using JNL in standalone applications is practically no different from using regular Java libraries. Those. the prerequisite is to locate the JNL in a place known to the class loader (it is usually sufficient to place the library somewhere in the classpath). However, it is sometimes necessary to place the JNL in a directory that is directly accessible to the OS loader.

But if an application is designed to work on any application server, then simply sticking a JNL WAR / EAR file and putting it along with the application itself onto the server will not work. The reason is obvious: a possible security hole. An application with JNL accesses the operating system with application server privileges (this is at a minimum). The application server has its own security system, and it will be somehow not pathos-based to bypass its user application.

Thus, if you put JNL directly into an EAR or WAR, then the application, of course, will fail. But when you try to call the JNI code, you will get an exception (most likely it will be java.lang.UnsatisfiedLinkError with Native Library diagnostics already loaded in another classloader).
')
So, using JNL on the application server is absolutely impossible? In fact, it is not. It is just necessary to explain to the application server itself that JNL is used legally (and, probably, its use for the application server itself will be more or less safe). Well, then begin the subtleties that depend on the specific application server.

In any case, when compiling Java code, you need to specify the path to the used JNL (to be able to refer to the Java classes contained in it), but you don’t need to pack it into an EAR / WAR or JAR file for deployment. Further actions depend on the target application server.

Glassfish 3.x, 4.x

You must copy the JNL to domain-dir / lib or domain-dir / lib / ext (with this, JNL will be available for all applications). No additional changes are required in the Glassfish configuration and in the user application.

WildFly, Jboss

Everything is a little more complicated here. The sequence of actions is as follows:

• inside $ JBOSS_ROOT / modules we create a set of directories like:

    $ JBOSS_ROOT / modules / path / to / my / module / main 

• Copy the required JNL to the directory:

    $ JBOSS_ROOT / modules / path / to / my / module / main 

• ibid create a text file with the name module.xml and the following contents:
  

   <?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.3" name="..."> <resources> <resource-root path="_JNL.jar"/> </resources> </module> 

  
  
• in the application that JNL wants to use, in the MANIFEST.MF file (located in / META-INF) add the line:
  

    Dependencies: desired.name.my.the.module export 

  
  The “export” parameter is added if we want to make our JNL available not only for the current module, but also for other modules that it contains (for example, inside an EAR).