This content has been marked as final. Show 12 replies
This error means that the truststore specified was not found. It's a very strange thing to be doing for the client to be downloading a truststore from the server, and particularly so to be downloading it via HTTPS, which is the channel the truststore is verifying. There is a security design problem here somewhere, regardless of the fact that it worked before.
Which version of 7 is being used?
There were some bugs in early releases of 7 related to certs. Do you see the failure if you used 7u9 (the latest GA release) or 7u12, the latest EA?
You should have a look at what flags are set in the JNLP
Setting the Xbootclasspath/a:path in the JNLP file may be the cause here.
Specify a semicolon-separated path of directires, JAR archives, and ZIP archives to append to the default bootstrap class path.
Here are examples that you can look at and compare:
We have some new findings.
We find that the javaws.jar in jre6 can not be run with javaw.exe in jre7, but javaws.jar in jre1.5 can be run with javaw.exe in jre7.
1. jre6's javaws.jar runing with javaw.exe in jre7 will be no any output. <= this is the case with issue.
"c:\program files\java\jre7\bin\javaw.exe" "-Xbootclasspath/a:c:\program files\java\jre6\lib\javaws.jar;c:\program files\java\jre6\lib\deploy.jar;c:\program files\java\jre6\lib\plugin.jar" -classpath "c:\program files\java\jre6\lib\deploy.jar" -Djava.security.policy="file:c:\program files\java\jre6\lib\security\javaws.policy" -DtrustProxy=true -Xverify:remote -Djnlpx.home="c:\program files\java\jre6\bin" -Dsun.awt.warmup=true -Djnlpx.origFilenameArg=https://xxxxxx/lsm.jnlp -Djnlpx.remove=false -Djnlpx.splashport=60986 "-Djnlpx.jvm=c:\program files\java\jre7\bin\javaw.exe" com.sun.javaws.Main https://xxxxxx/lsm.jnlp
2. but we use jre1.5's javaws.jar runing with javaw.exe in jre7, will be OK.
"c:\program files\java\jre7\bin\javaw.exe" "-Xbootclasspath/a:c:\program files\java\jre1.5.0_20\lib\javaws.jar;c:\program files\java\jre1.5.0_20\lib\deploy.jar;c:\program files\java\jre1.5.0_20\lib\plugin.jar" -classpath "c:\program files\java\jre1.5.0_20\lib\deploy.jar" -Djava.security.policy="file:c:\program files\java\jre1.5.0_20\lib\security\javaws.policy" -DtrustProxy=true -Xverify:remote -Djnlpx.home="c:\program files\java\jre1.5.0_20\bin" -Dsun.awt.warmup=true -Djnlpx.origFilenameArg=https://xxxxxx/lsm.jnlp -Djnlpx.remove=false -Djnlpx.splashport=60986 "-Djnlpx.jvm=c:\program files\java\jre7\bin\javaw.exe" com.sun.javaws.Main https://xxxxxx/lsm.jnlp
Furthermore, I find javaws.jar in jre6 will depend on sun.jkernel.*, which is part of rt.jar in jre6. But in jre7's rt.jar, sun.jkernel.* is removed.
I guess that's the reason why jre6's javaws.jar cannot be run in jre7 (javaw.exe)
do you have any suggestions? or can you please confirm my guess?
EJP wrote:Indeed. One has to review what one is really proving. In this case: you can apparently boot javaws of JRE 5 with JRE 7, but not the one of JRE 6. Its cute trivia, but utterly meaningless in any way. I do believe the problem was with a very odd way to employ certification, not with booting up webstart.
All these experiments are pointless. Nobody ever intended that parts of a JRE would would with parts of a different version. Don't pursue this line of enquiry.
OK, thanks anyway.
It isn't experiment, it's the reality of our product.
Our GUI need to be co-exist with another GUI (need run in JRE7) in a WinXP PC, however, our GUI can olny be runing in JRE6.
So the PC MUST install JRE6 and JRE7 and both enabled.
In this circumstance, Our GUI will triger command C:"\Program Files"\Java\jre6\bin\javaws https://xxxxx/platusm.jnlp, and the detailed parameter of the command can be seen in http://img.my.csdn.net/uploads/201211/13/1352800884_9032.jpg
In order to find the thing behind, we need to do some futher study.
a) jre6's javaws.jar runing with javaw.exe in jre7 will be no any output.
b) but we use jre1.5's javaws.jar runing with javaw.exe in jre7, will be OK.
if you have time, you can to try this.
Edited by: user9051557 on Nov 22, 2012 4:55 PM