JDK-7116999 : Update JNLP of newer server file is not performed.
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_7
  • CPU: x86
  • Submitted: 2011-12-01
  • Updated: 2013-01-08
  • Resolved: 2011-12-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7u4Resolved
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) Client VM (build 21.1-b02, mixed mode, sharing)

reproducible since Java 1.6.0_22

ADDITIONAL OS VERSION INFORMATION :
Windows,
Windows XP with default configuration,
Other Windows, if cache path contains spaces

A DESCRIPTION OF THE PROBLEM :
If the path to the Java cache contains spaces the JNLP file will never get updated.

The problem is that the Launcher seems not to be able to locate the cache file when trying to compare to the current server file. The new file is never requested for download.

If shortcut target is created containing escaped extra quotes (\"), the download will be done to a new location and the shortcutcut target will be modified to point to that newly downloaded JNLP cache file, e.g.:

C:\Java\jre\bin\javaws.exe -localfile -J-Djnlp.application.href=http://myserver:8080/MYPATH/mywebstart.jnlp "\"C:\Java\cache path containing spaces\6.0\23\22e27657-13f129e6"\"

This used to work in 1.6.0_21 (without extra quotes).

REGRESSION.  Last worked in version 6u29

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.) use default cache location under Windows XP
or
set cache dir to point to a path containing spaces, e.g.:
deployment.user.cachedir=C\:\\cache path containing spaces

2.) download any application containing a shortcut request within jnlp

3.) make a change to the jnlp file on the server side

4.) doubleclick shortcut to download the new jnlp file


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The current server JNLP file should get downloaded to cache.
The shortcut should point to the current JNLP file.

ACTUAL -
The JNLP file is not downloaded.

Jar updates (for jar files already contained in the old JNLP file) are downloaded.

The application is -partly- updated, but the JNLP file is still old and any new Jars are missing.

This is very critical, because the user might not even notice straight away that there are parts of the application missing (in case the JNLP was updated to use new jar files)

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error is raised, but the Update JNLP just is not done -
No request is send to the server, please see trace:

network: prepareToLaunch: offlineOnly=false
network: Cache entry found [url:
http://myserver:8080/MYPATH/mywebstart.jnlp, version: null] prevalidated=true/0
temp: new XMLParser with source:
temp: <?xml version="1.0" encoding="UTF-8"?>

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Any jnlp file containing requesting shortcut:

<?xml version="1.0" encoding="UTF-8"?>
<!-- JNLP File to use for Java Webstart  -->
<jnlp
  spec="1.0+"
  codebase="http://myserver:8080/MYPATH"
  href="myApp.jnlp">
  <information>
    <title>Standard Client</title>
    <vendor>Company Name</vendor>
    <description>Webstart configuration for MYAPP</description>
    <icon href="myicon.png"/>
    <shortcut online="true">
      <desktop/>
      <menu submenu="MYAPP"/>
    </shortcut>
  </information>
  <update check="always" policy="always"/>
  <security>
      <all-permissions/>
  </security>
  <resources>
    <j2se version="1.6+" initial-heap-size="128M" max-heap-size="256M"/>
...
some jar files
...
 </resources>
  <application-desc main-class="com.xxx">
...
  </application-desc>
</jnlp>

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
There is no feasible workaround for this.
This needs to be resolved.

Comments
EVALUATION The windows xp part (which caused by extra escape chars "\\\\" failed path comparison with cache directory path string wihout escape chars) has been fixed by CR 7063209 in 8, 7u2 and 6u30. The problem with cache dir path has lower-case drive letter is now fixed in 8 and being ported to 7u4 by CR 7119603.
10-12-2011