UnableToLaunchTheApplication JRE 1.7.0_45

Classic Servoy
1

Hi,

my customers have upgrated their Macs to OS X Mavericks and Java 1.7.0_45-b18.
The server is still running with Mac OS X 10.8.5, Java 1.6.0_51 and Servoy 6.1.6 -1439.

Now the Smart Client won’t open and we get the Application Error dialog “Unable to launch the application”.
The .jar files in the application_server direction are signed by the newest signtester.jar version (1.3) from 10/24/2013.

This is what I get:

Java Console:

CacheEntry[http://xxxxxx:8081/servoy-client/yyyyyy.jnlp]: updateAvailable=true,lastModified=Thu Nov 14 20:28:38 CET 2013,length=-1
CacheEntry[http://xxxxxx:8081/servoy-client/yyyyyy.jnlp]: updateAvailable=true,lastModified=Thu Nov 14 20:31:14 CET 2013,length=-1
#### Java Web Start Error:
#### The Java security settings have prevented this application from running. You may change this behavior in the Java Control Panel.

Exception:

com.sun.deploy.security.BlockedException: The Java security settings have prevented this application from running. You may change this behavior in the Java Control Panel.
	at com.sun.deploy.security.SandboxSecurity.showBlockedDialog(Unknown Source)
	at com.sun.javaws.security.AppPolicy.grantUnrestrictedAccess(Unknown Source)
	at com.sun.javaws.security.AppPolicy.addPermissions(Unknown Source)
	at com.sun.jnlp.JNLPClassLoader.getPermissions(Unknown Source)
	at java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
	at com.sun.javaws.Launcher.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.SecurityException: JAR manifest codebase mismatch for http://xxxxxx:8081/lib/j2db.jar
	at com.sun.deploy.security.DeployManifestChecker.verify(Unknown Source)
	at com.sun.deploy.security.DeployManifestChecker.verify(Unknown Source)
	... 17 more

How can I get the solution running?

2

Now I got back to Java 1.6.0_65 from the JavaForOSX2013-05.dmg,
created the symlink and re-enabled the Java Web Start.

But the solution won’t start and the Smart Client does not open!?

The Application Error Exception is:

java.lang.SecurityException: JAR manifest codebase mismatch for http://xxxxxx.org:8081/lib/j2db.jar
	at com.sun.deploy.security.DeployManifestChecker.verify(DeployManifestChecker.java:126)
	at com.sun.deploy.security.DeployManifestChecker.verify(DeployManifestChecker.java:84)
	at com.sun.javaws.security.AppPolicy.grantUnrestrictedAccess(AppPolicy.java:223)
	at com.sun.javaws.security.AppPolicy.addPermissions(AppPolicy.java:130)
	at com.sun.jnlp.JNLPClassLoader.getPermissions(JNLPClassLoader.java:459)
	at java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:235)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
	at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at com.sun.jnlp.JNLPClassLoader.findClass(JNLPClassLoader.java:348)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1587)
	at com.sun.javaws.Launcher.run(Launcher.java:141)
	at java.lang.Thread.run(Thread.java:695)

All that behavior is not nice and a big problem for our customer…

3

The Error is clearly explaining what is wrong! You signed it with a wrong codebase! For example if you signed it with a codebase:

http://www.mydomain.com

and you are downloading the client from:

http://www.myotherdomain.com

than your solution is not allowed to start.

4

Thank you Harjo,
you are right! I forgot the ext. URL for the signtester tool.
Now the solution is running with Java 1.6.0_65 as well, but

with Java 1.7.0_45 I always get the Java security dialog on every programstart :? ?!

Do you have a solution for that?

Regards
Thomas

5

Did you sign it with an official certificate? Or a self signed? Now with Java 7 the time has come to sign with an official signing certificate!

6

tgs:
with Java 1.7.0_45 I always get the Java security dialog on every programstart :? ?!

i think that’s the bug in that _45 release. Hopefully fixed in the next

7

The bug in that release, is the little yellow balloon, that still gives a warning.
When signed with an official certificate, you can accept that (only once) and it will not ask you again.

If you signed it with an selfsigned certificate, you get ‘heavier’ warning, and you have to accept it every time, when launching!

8

For me my selfsigned certificate is more secure than an “official” certificate 8) .
Can we trust the certification center… ?

But anyway, I will try it with my official certificate.

9

its only more secure if you get your certificate in a secure way to all your clients (that then import that into there certificate store)

Else it is not secure, there can be something in the middle just as easy.

But yes a self signed certificate where you securely distribute the certificate to all your clients for importing is secure.
(and java will not complain then because the certificate is in its local store so it sees it as a valid one)

10

So if I understand this correctly:
because of this codebase setting you need to sign all jars with the domain/ip your downloading the application from.
This is a nice one with an application running ‘on premises’, this means you need to sign everything per customer?!?!

Really, tell me this isn’t true and Oracle is just making a bad practical joke…

11

mboegem:
This is a nice one with an application running ‘on premises’, this means you need to sign everything per customer?!?!

Really, tell me this isn’t true and Oracle is just making a bad practical joke…

This is not a joke!
This way you prevent jar loading from other/different locations!

But you don’t HAVE to sign it for every customer.
First you can add multiple domainnames, but also use wildcard’s

like this *.mydomain.com, will allow, it runs from: mycustomer1.mydomain.com, mycustomer2.mydomain.com
that way, you only have to add an A record for every new customer.

here you find the full explanation: http://docs.oracle.com/javase/7/docs/te … ifest.html
The signtester-tool, now supports al these (new) properties!

12

Thnkx Harjo, will try.