Problem with Sintpro scanner plugin

Classic Servoy
1

I’ve been testing the Sintpro scanner plugin. It works great in developer, but in server I get this error:

Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: SK.gnome.twain.TwainManager.initialize(I[B[BZ)V
	at SK.gnome.twain.TwainManager.initialize(Native Method)
	at SK.gnome.twain.TwainManager.<clinit>(TwainManager.java:85)
	at com.sintpro.plugin.scanner.GetTwainSources.<init>(GetTwainSources.java:13)
	at com.sintpro.plugin.scanner.sintproScannerPluginProvider.js_GetTwainSources(sintproScannerPluginProvider.java:220)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:179)
	at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:353)
	at org.mozilla.javascript.optimizer.OptRuntime.callProp0(OptRuntime.java:111)
	at org.mozilla.javascript.gen.c113._c0(Unknown Source)
	at org.mozilla.javascript.gen.c113.call(Unknown Source)
	at org.mozilla.javascript.optimizer.OptRuntime.callProp0(OptRuntime.java:111)
	at org.mozilla.javascript.gen.c163._c0(onshow:28)
	at org.mozilla.javascript.gen.c163.call(onshow)
	at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:387)
	at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3127)
	at org.mozilla.javascript.gen.c163.call(onshow)
	at com.servoy.j2db.scripting.Ztb.executeFunction(Ztb.java:122)
	at com.servoy.j2db.Zwb.Za(Zwb.java:946)
	at com.servoy.j2db.Zwb.Za(Zwb.java:237)
	at com.servoy.j2db.Zwb.ZO(Zwb.java:286)
	at com.servoy.j2db.Zwb.access$1400(Zwb.java:100)
	at com.servoy.j2db.Zzb.run(Zzb.java:2)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

Could this be because of unsigned jars? It is different from the other messages I’ve gotten that were caused by the jars.

2

It is more a hint that it can not find a certain method.

I would ask Nicola if I were you.

3

Hi Michael, can you tell me which servoy version are you using and which client operating system? I need some informations to understand what’s happening. For the signature of the plugin I’m working on it and a new version should be available soon.

4

Thanks Nicola. It’s Windows 7 64 bit, Java 1.6u20, Servoy 5.1.3. I should mention that I believe the error occurs when calling plugins.sintproScannerPlugin.GetTwainSources()

BTW - the plugin works great in developer and we will be incorporation it into our solution when we have finished testing.

5

Further info - smart client run off the same server -

Computer with Vista 32 bit, java 1.6u20 has no problem.
Computer with Win 7 32 bit, java 1.6u17 has no problem.
Computer with Win 7 64 bit, java 1.6u20 (64 bit) gets error.

6

Ok, I will check it out, probably I will need to update the underlying libraries to support Windows 7 64bit. Will let you know when ready.

7

in a 64 bit jvm you need 64 bit binaries… 32 bit wont run.

so that is the case yes.

8

So out of curiosity, why does it run in developer?

9

what java does your developer run? 64 bit or 32 bit?

10

When I run developer, I don’t see java running at all in Windows task manager. Just the servoy.exe which is 32 bit. Why is that? Also, why no problem with any other jars in 64 bit? I use a number of third party plugins and beans.

11

so if the devleoper is 32 bit (in the task manager of win7 you can see that with *32 behind the name) then you will load the 32 bit native libs

But webstart sees a 64 bit jvm when starting up the client so then the 32 bit libs dont cut it and it needs 64 bit libs.