Certificates expired, new deploy throws exception, then launch again =works

Our certificate to sign our JWS deployed jars is about to expire so we signed them with a new cert and in development when we re-deploy with the new jars the JWS client throws exceptions. But if you launch it again it will work, but ONLY from the web browser the desktop shortcut link will stay broken forever. Now upon being fixed by a 'launch from webpage twice' the desktop shortcut becomes fixed.

1st Launch after deploying with new cert:

Java Console:

#### Java Web Start Error:

#### JAR resources in JNLP file are not signed by same certificate

Application Error(pop up window) > Details(button):

Has three tabs,"Launch File","Exception","Console".

"Exception":

...<the launch file pasted>...

</jnlp> ]

at com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(Unknown Source)

at com.sun.javaws.LaunchDownload.checkSignedResources(Unknown Source)

at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)

at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)

at com.sun.javaws.Launcher.launch(Unknown Source)

at com.sun.javaws.Main.launchApp(Unknown Source)

at com.sun.javaws.Main.continueInSecureThread(Unknown Source)

at com.sun.javaws.Main$1.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

"Console":

Java Web Start 1.6.0

Using JRE version 1.6.0 Java HotSpot(TM) Client VM

User home directory = C:\Documents and Settings\MY_LOGIN

-

c:clear console window

f:finalize objects on finalization queue

g:garbage collect

h:displaythis help message

m:print memory usage

o:trigger logging

p:reload proxy configuration

q:hide console

r:reload policy configuration

s:dump system and deployment properties

t:dump thread list

v:dump thread stack

0-5: set trace level to <n>

-

#### Java Web Start Error:

#### JAR resources in JNLP file are not signed by same certificate

I have tried deleting all of the *pack.gz files and removing the old jars so Jardiff won't try to create a delta across keys (should it matter?). And that didn't change anything.

Message was edited by:

javaunixsolaris

[2452 byte] By [javaunixsolarisa] at [2007-11-27 6:10:53]
# 1

1.) are you using version based downloading ? (if so, you would need to bump the version on all the resigned jars.)

2.) do you specify <offline-allowed> ? If it is specified, new jars will only be downloaded the first time if the server responds within 1.5 seconds that an update is available.

3.) What version of Java Web Start are you using ?

If you are specifying some jars as "lazy", they might not be updated immeadiately for some older versions. Also if you are using JDK 6, you can specify <update check="always"/> to insure update is always checked for w/o timeing out in 1.5 seconds as may be the case if the default <update check="timeout"/> is used.

/Andy

dietz333a at 2007-7-12 17:16:43 > top of Java-index,Desktop,Deploying...
# 2

> 1.) are you using version based downloading ? (if so,

> you would need to bump the version on all the

> resigned jars.)

=Yes and I DID NOT bump the version. TODO

> 2.) do you specify <offline-allowed> ? If it is

> specified, new jars will only be downloaded the first

> time if the server responds within 1.5 seconds that

> an update is available.

=No.

> 3.) What version of Java Web Start are you using ?

> If you are specifying some jars as "lazy", they might

> not be updated immeadiately for some older versions.

> Also if you are using JDK 6, you can specify <update

> check="always"/> to insure update is always checked

> for w/o timeing out in 1.5 seconds as may be the

> case if the default <update check="timeout"/> is

> used.

=6.0; <update check="always" policy="always"></update>; we do have some lazy jars TODO I'll try that next.

Thx Andy all good things to try. Here's our production JNLP (currently pre-new-cert): https://www.trustamerica.com/TCAdvisorII/tcAdvisor.jnlp

javaunixsolarisa at 2007-7-12 17:16:43 > top of Java-index,Desktop,Deploying...
# 3

Getting rid of all the lazy jars didn't change the behavior. So then I tried option#1 and appended "-nc" (aka dash new cert) to all of my versioned JARs and that fixed it!...well fixed it MOSTLY the web page works 100% now but the desktop shortcut caches the JNLP file. So they can run the desktop shortcut ad infinitum and the JNLP will NOT CHANGE to the new one. So I guess I have a bug to report...

javaunixsolarisa at 2007-7-12 17:16:43 > top of Java-index,Desktop,Deploying...