Custom JNA Library Version Support

[suomarte]

History

Through all Glassfish versions, at least since 5.1, the module path/to/glassfish/glassfish/modules/libpam4j.jar also contains a JNA version com/sun/jna. In the days of Glassfish 5.1 and Java SE 8 I was able to override the JNA version in libpam4j.jar with a higher version of JNA by loading it through the lib ext mechanism. Unfortunately today with Glassfish 7.0.1 and Java SE 17 the ext dirs mechanism does not exist anymore.

My Use Case

Glassfish 7.0.1 provides in libpam4j.jar a JNA version lower than 5.12.1. An integration of a Jaybird DB requires Jaybird 5.0.1.java11, which requires JNA 5.12.1. A JNA version simply placed in path/to/glassfish/glassfish/domains/domain/lib/jna.5.12.1.jar is ignored. There seems not to be a good way to override the JNA version in libpam4j.jar

Workaround

As I always stay in the windows environment with Glassfish, I assume the libpam4j is actually not used. Therefore I removed the JNA package from libpam4j.jar. Afterwards my own JNA library is loaded from path/to/glassfish/glassfish/domains/domain/lib/jna.5.12.1.jar

Request

The workaround works, but possibly it is not a good approach for future glassfish versions. Do you have better suggestions to solve this?

[OndroMih]

A proper solution on Java 11+ would be to add your JAR at the beginning of the GlassFish classpath, so that it gets a higher priority than classes in GlassFish. However, it's not that easy in GlassFish. The asadmin launcher assembles the classpath argument to the JVM. It's not possible to set the classpath with JVM options in GlassFish configuration because any -cp argument will be ignored by the GlassFish launcher. There's a way to define the class path prefix in the JVM options and it should work, but it's a deprecated functionality and it's only possible to do that using asamin command or editing domain.xml, not via the Admin Console.

In fact, the classpath prefix and suffix options were deprecated when OSGi was introduced to GlassFish a long time ago and the lib ext mechanism was present. With the lib ext mechanism gone, I think GlassFish should revert this deprecation and actually endorse this feature to replace the lib ext functionality.

[suomarte]

@OndroMih, thank you for investigating in this issue. Since I don't know of any reason why the classpath pre- and suffix should not be re-enabled, I think this is a possible solution.

There are more bug reports referring to the same root cause:

• Removed ext lib mechanism from Java SE
• Removed classpath prefix and suffix mechanism from Glassfish
• No replacement for the removed classpath mechanisms

More affected bug reports:

• #24350
• #24212

[dmatej]

Actually GF uses JNA 5.13.0, see https://repo1.maven.org/maven2/org/glassfish/main/libpam4j/libpam4j/7.0.1/libpam4j-7.0.1.pom, so it is newer than 5.12.1, not older.

CP prefix and suffix were in GF2. The reason of removal is probably that since GF3 server's dependencies are managed by Felix and OSGI. So I would say that there is no way back (without OSGI removal).

Another issue to consider is a separation. If you want to use different version of dependencies than those already provided by GlassFish, results may be unpredictable. But ... when you need another version of the JNI just for the application, OSGI should be capable to do that somehow and we should document/implement it. Any volunteers?

[mz1999]

You can package jna-5.12.1.jar in your application. If it is a web application, you can place jna-5.12.1.jar in WEB-INF/lib directory. Then add the following configuration to glassfish-web.xml:

<glassfish-web-app error-url="">
  ...
  <class-loader delegate="false"/>
  ...
</glassfish-web-app>

The configuration <class-loader delegate="false"/> here tells Glassfish to load classes from the application's class loader first, rather than from the parent class loader (Glassfish's class loader) first. This ensures that the application prioritizes the JNA library in the WAR package, rather than the version provided by Glassfish.

[OndroMih]

A solution would be to implement a similar feature as in Payara: https://github.com/payara/Payara/pull/5707 - add lib/ext directory to the classpath on Java 9+.

[zsuiqiang]

All Modify datetime of files in libpam4j.jar are "1980-02-01 00:00". So payara rebuild this jar file ,it work!

[avpinchuk]

All Modify datetime of files in libpam4j.jar are "1980-02-01 00:00". So payara rebuild this jar file ,it work!

It works because Payara's libpam4j.jar contains repackaged jna-5.12.1 and binding libraries.

[github-actions[bot]]

This issue has been marked as inactive and old and will be closed in 7 days if there is no further activity. If you want the issue to remain open please add a comment

[github-actions[bot]]

This issue has been marked as inactive and old and will be closed in 7 days if there is no further activity. If you want the issue to remain open please add a comment