Servoy Forum

Hi,

Is there a workaround for this? Clients do not have this issue, just started on the test server.

Any other methods to use COM methods from Servoy?

Recently getting this error on WebClient. Running Tomcat 9, Servoy 2020.12, Servoy COM 1.2 on Windows Server 2012R2.

Running servoy ROOT.war and using .servoy as updates to the application.

The COM is deployed within the .war.

Indications on the web that this should be in the apache common lib, and not in the webapps directory.

Coincidentally, I changed these two properties to 'true' and restarted a couple days ago, but this is the first time to use the web client.
Not sure if this is related, but changing back to false did not change the ability to access the COM object.

Code: Select all

isOverwriteDeployedDBServerProperties=false
isOverwriteDeployedServoyProperties=false

thanks,
--Joe.

java.lang.UnsatisfiedLinkError: Native Library C:\Users\STSX\.servoy\jacob-1.19-x64.dll already loaded in another classloader
at java.lang.ClassLoader.loadLibrary0(Unknown Source) ~[?:1.8.0_281]
at java.lang.ClassLoader.loadLibrary(Unknown Source) ~[?:1.8.0_281]
at java.lang.Runtime.load0(Unknown Source) ~[?:1.8.0_281]
at java.lang.System.load(Unknown Source) ~[?:1.8.0_281]
at com.jacob.com.LibraryLoader.loadJacobLibrary(LibraryLoader.java:151) ~[?:?]
at com.jacob.com.JacobObject.<clinit>(JacobObject.java:110) ~[?:?]
at com.servoyguy.plugins.servoycom.RemoteCOM.<init>(RemoteCOM.java:16) ~[?:?]
at com.servoyguy.plugins.servoycom.ClientScriptObject.js_getNewClientJSCOM(ClientScriptObject.java:29) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_281]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_281]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_281]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_281]

The additional .war file that is used internally also had the ServoyGuy COM plugin, which was unnecessary.

Removing the COM plugin from .war file fixed it.

The architecture is that the ROOT.war file provides two applications. The applications are updated as Solution updates, not integrated into the .war. The SECOND.war file is just for internal use, but is in a different container, and resides on the test server, and is the reason it has never manifested at the client.

How this would work in a production environment would really suck if solutions had to be distributed by .war updates, particularly if the COM issue between the two solutions remained and the solutions had to be provided by the .war distribution instead of .server solutions. The clients vary over their IT commitments, so stopping and restarting a production environment for a .war update is problematic, and current Servoy updates can still be made through SSL remotely.

So, I'm suggesting here, is that updating how Servoy defines the properties and databases forced the ROOT.war to attach the COM library AFTER the SECOND.war file already had it. Apache Tomcat doesn't like to share libraries, so that was the problem with the Jacob library above. Removing the COM library from the SECOND.war export removed that problem. (Stopping and redeploying SECOND.war fixed it, but would not likely have resolved the COM library problem.)