0

vFabric tc server fails to load my JNI libraries when starting a Spring bean that executes 'System.loadLibrary("...")'. Indeed, I need to execute some JNI shared library from my Spring beans deployed in vFabric tcServer edition (STS) Spring Tools Suite.

Although I followed the advice in "Customizing the environment or JVM options for vFabric tc Server (2030216)" the error kept poping out: "nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [my.JniServiceFactory]: Constructor threw exception; nested exception is java.lang.UnsatisfiedLinkError: no myJNIsharedLib in java.library.path"

I further discovered error in wrapper.log file in the tc server instance .../bin/winx86_64 directory telling: Unable to open configuration file. C:\java\SpringTools\vfabric-tc-server-developer-2.9.6.RELEASE\base-instance\bin\winx86_64\wrapper.conf and also found errors when executing the wrapper at command line: wrapper -q ..\..\conf\wrapper.conf, yielding wrapper | OpenSCManager failed - Access is denied. (0x5), which suggested a UAC issue. So I elevated my windows account to Administrator and even turned off UAC... which solved the wrapper.exe error but did not solve the UnsatisfiedLinkError when starting my app in tc server.

I also discovered a 'setenv.bat' file under the tc server instance directories containing the line 'set JAVA_LIBRARY_PATH=' that invites you to define it, but no effect. I also tried setting a global environment variable JAVA_LIBRARY_PATH under my system properties, hence available when starting Spring Tools and then the tc server... no way.

Bernard Hauzeur
  • 2,317
  • 1
  • 18
  • 25

1 Answers1

0

Actually, the solution I discovered holds under the Eclipse RUN configurations.

In Eclipse menu run > Run configurations... > VMware vFabric developer Edition > Arguments tab > VM arguments: add to the long listing the extra -Djava.library.path=\java\git\MySharedLibRepo and restart the tc Server... this solves the issue.

Do also ensure under MS-Windows that the target JNI native library that is loaded by System.loadLibrary("...") bears the exact basename of the .dll native library (hence without .dll extension).

And indeed no Administrator permission is required. A regular Windows user account is fine.

Bernard Hauzeur
  • 2,317
  • 1
  • 18
  • 25