Loading DLL from WAR file

[emai...@gmail.com]

Hi -

Trying to load a DLL from a WAR file that is deployed to Glassfish. I've tried placing the DLL file into WEB-INF/class/foo.dll and WEB-INF/lib/foo.dll. I've also tried packaging the DLL inside a jar file which is then packaged in the WAR in the WEB-INF/lib directory. In all cases Native.loadLibrary("fooDLL", FooDLL.class) fails with and unsatisfied link error. When I drop the DLL in C:\Windows\System32 it loads. 

I also tried following bullet point #3 from https://github.com/twall/jna/blob/master/www/GettingStarted.md which discusses {OS}-{ARCH}/{LIBRARY} on the classpath.  In my case my "os.name" reports "Windows 7" and "os.arch" reports "amd64" so based on the code in NativeLibrary.java and Platform.java I tried both WEB-INF/lib/win32-x86-64/foo.dll and WEB-INF/classes/win32-x86-64/foo.dll but that didn't pan out.  This is with JNA 4.1.0 and I have a Windows 64 bit binary. 

Looking for advice on this, thanks,

-Noah

[Timothy Wall]

Run with -Djna.debug_load=true to see the places that JNA is attempting to load the dll, then move it to one of the locations indicated.

> --
> You received this message because you are subscribed to the Google Groups "Java Native Access" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[emai...@gmail.com]

Yes, I'd done that early on and never saw any log messages. I thought perhaps Glassfish logging was eating them so I cranked up logging on the appender that is related to System.out which JNA is using but still saw none. At some point I noticed that the JNA line numbers referenced in the stack trace related to failing to load the DLL did not jive with version 4.1.0 which I was bundling in my WAR. I had also tried using jna.nosys=true but still saw this line number discrepancy. Prompted by this I started digging around Glassfish and found that they were bundling an old version (3.2.2) in a application server OSGi module JAR (libpam4j-repackaged.jar) which was getting in the way of things. This old version doesn't support jna.debug_load, or jna.nosys which explains both why I wasn't seeing logging and my bundled JNA was not being picked up. To work around this I repackaged the JAR w/4.1.0 and filed the following ticket:

https://java.net/jira/browse/GLASSFISH-21367

Aside from that, is there a way to verify that nosys is actually working as intended? I want to make sure the property is being picked up and I am actually using the bundled JNA vs the new one that I repackaged. Thanks,

-Noah

[Timothy Wall]

> On Jun 1, 2015, at 1:30 PM, emai...@gmail.com wrote:
>
> Aside from that, is there a way to verify that nosys is actually working as intended? I want to make sure the property is being picked up and I am actually using the bundled JNA vs the new one that I repackaged. Thanks,

Well, you *could* install a system version of JNA that bombs immediately. It’s a bit tough to test in isolation (i.e. unit tests).

There is one library load call that depends on the system to find the library in question; when jna.nosys is set, that call is skipped. In all other cases, an explicit path is used to load the library.

T.