I could see Java web start downloading the application and dependent jars locally, but then it gave me an error message: “Unable to launch the application”. In the Java console I could see the following error message:
Java Web Start Error:
JAR resources in JNLP file are not signed by same certificate
If I click on the Details button I could see one of the our plugin jars’ jnlp listed under the Exception tab. However, if I run the signtester.jar in the application_server directory and most of the jars did “verify”, including the once referenced in the Exception tab. The only ones that did not verify were:
The plugin that it seems to complain about is our own.
I don’t think tomcat-juli.jar is downloaded to the client. It seems the signtester.jar utility (recomended on this forum) checks all jars without making a distinction which are server-side and which are supposed to be downloaded to the client.
What are the steps I need to take to make sure own plugins are signed by the same key as other Servoy jar files downloaded to the client when starting a smart client application from the server using Java web start?
The signtester tool is only looking for jars in application_server that are in:
/beans
/lafs
/lib
/plugins
and for the BrowserSuite, also in /server/webapps/ROOT/browser_suite
That’s all.
tomcat-juli.jar is supposed to be in /server/lib and the signtester is not looking into /server
So either you have put it in /lib where it’s not supposed to be, or you are running the toold from the wrong location.
You shouldn’t put your own jars in /lib - only in lafs, beans and plugins.
The root directory (where you should put the signtester.jar in, along with your keystore) is Servoy/application_server.
I ran signtester.jar from Servoy/application_server. I did another test and it does seem our plugin deployment ant script places a copy of tomcat-juli.jar and a copy of tomcat-juli-adapters.jar into Servoy/application_server/lib directory.
As far as the original issue goes, the solution turned out to be simple. All jar files referenced in a single JNLP file need to be signed by the same key as the error message in the Java console implies. Using the jnlp resource extension mechanism or removing the reference to the jar signed by a different key resolves the issue.
One reason for that is that we need to integrate the Tomcat logging so that it uncaught exceptions would show up in the Servoy Admin console and in the servoy log file. This is for a separate web client application that gets deployed to the same Servoy application server as the smart client app I was trying to run earlier. Please see https://support.servoy.com/browse/SVY-1017
I see. But in any case this loggin will happen on the server side for your web app.
The (smart) client doesn’t need these jars, so no need to add them to your jnlp whatsoever.
I’m hitting a similar problem. When trying to launch a SC from our linux server I get “JARs in JNLP file are not signed by same certificate”
When I try to resign the jars with the latest signtester.jar from servoyforge I get errors like this.
Verifiying dir: ./beans
Unsigning: IClock.jar
/home/servoy/application_server/./beans/IClock.jar unsigned
ERROR adding dummy classes in /home/servoy/application_server/./beans/IClock.jar error in opening zip file
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:127)
at java.util.jar.JarFile.<init>(JarFile.java:135)
at java.util.jar.JarFile.<init>(JarFile.java:114)
at net.stuff.servoy.utils.Repacker.addDummyClass(Repacker.java:112)
at net.stuff.servoy.utils.Repacker.repack(Repacker.java:43)
at com.servoy.jarsigner.SignerTest.dir(SignerTest.java:213)
at com.servoy.jarsigner.SignerTest.main(SignerTest.java:121)
The permissions are
-rw-r–r-- 1 servoy servoy 34177 Jun 14 07:02 IClock.jar