cancel
Showing results for 
Search instead for 
Did you mean: 

JNI under MobileEngine

Former Member
0 Kudos

Hi all,

we have problem with calling native methods in MobileEngine context. The DLL is where it should be, all seems to be OK, but when System.loadLibrary() is called it raises an exception like

java.lang.UnsatisfiedLinkError: no <Our DLL name> in shared library path

at java.lang.Runtime.loadLibrary(Runtime.java)

at java.lang.System.loadLibrary(System.java)

at .... etc.

The same class works perfectly when it's called outside tomcat. In the forums we have found some information, that there are problems with JNI under tomcat/servlet containers.

Does have someone more information about? Does have SAP some patch or workaround in ME on that problem?

Thanks in advance,

best regards

Accepted Solutions (0)

Answers (1)

Answers (1)

stefan_schwing
Active Participant
0 Kudos

Hi, could you provide a little more info, like where is the .dll located, what'S your java.library.path when your class is running. Cheers, stefan

Former Member
0 Kudos

The .DLL is located in directory "\Windows". (The device is a PocketPC, it's not a desktop machine).

The java.library.path was null at first, but when is set to "\Windows" there is no difference. Furthermore if I use System.load() instead of System.loadLibrary() and I give the absolute path as argument the problem is still not solved - again there is a "UnsatisfiedLinkError".

There are assumptions, that the problem is in the tomcat's ClassLoader. Any other ideas?

Regards

stefan_schwing
Active Participant
0 Kudos

Hmm, strange...

You say that you set hte java.library.path to \windows, when exatly do you do that ? If you do it when the VM has already started, it might be too late, you have to pass that as an VM argument via

-Djava.library.path=\windows.

But the strange thing is that it is null from the beginning. Just to make sure: When calling System.loadLibrary() you only pass in the .dll name, without the ".dll in the end:

System.loadLibrary("dllname") and not System.loadLibrary("dllname.dll")

Cheers, Stefan

Former Member
0 Kudos

Yes, of course I give just the name of the DLL without the extension. I write the extension only when I'm trying to use System.load(), instead of System.loadLibrary().

Also setting -Djava.library.path=\windows in the startup string doesn't work. It was one of the first things I have tried, but it just has no effect - the "java.library.path" property is still null :(. Thence behaviour we have assumed that the problem is in the more-than-one Classloaders in tomcat. The assumption comes by a colleague, that have more experience with tomcat, I personally have just a little bit idea from the tomcat's secrets.

Now we have solved the problem by other way, and we do not need to call native methods. But the problem still persists, and in the future I suppose we will have again a lot of 'Fun' with it.

Thanks to anyone who helps for the solution!

Best regards