This content has been marked as final. Show 3 replies
if you look into what desktop shortcut is you will notice it is basically request for javaws to use cached copy of JNLP file.
It is fragile and may break if cached jnlp file will be removed (and JNLP file update works as removal of old copy and creation of new copy with different name).
JRE6 was trying to ensure shortcuts gets updated once cache is updated but this did work well for all scenarios.
JRE7 uses different and more robust approach by using original application URL to lookup entry in the cache.
Unfortunately i am not sure if JRE7 solution was ported to JRE 6.
If your users can not upgrade to Java 7 (unless Java 7 has some blocking issue i'd recommend upgrade to 7u) then options you have are:
a) add custom code to create desktop shortcut (will need to sign your app and understand how shortcuts work on the target systems)
create it as
b) try to chase down reasons why JNLP file is getting removed and try working this around so removal is not needed
Possible root causes you may workaround:
- http server reports JNLP is updated every time (or does not provide last modified date, or expiration date)
- cache is getting cleared externally (e.g. by scripts)
If application do not change (or appear to be changed) and user is not upgrading JRE then unless deployment cache is "full" there are no reasons to remove cache entries i think
and then shortcut should work.
I have done a, only tested on one system so far. It seems to work at this time.
I have asked our IT guys to take a look at what might be going on, but I have not heard anything back.
What version of Java 7 is supposed to have the fix?
BTW, Thanks for your response.
One of the things I have noticed is that in some posts they will say it was fixed or resolved but never say how it was fixed or resolved.
The get a response from and never follow up.
I do not plan on doing that. We need to help each other the best we can.