United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7151950 REGRESSION:Webstart in 7u4 b13 not downloading new content
JDK-7151950 : REGRESSION:Webstart in 7u4 b13 not downloading new content

Details
Type:
Bug
Submit Date:
2012-03-07
Status:
Closed
Updated Date:
2013-06-22
Project Name:
JDK
Resolved Date:
2012-04-12
Component:
deploy
OS:
windows_7
Sub-Component:
webstart
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
7u4
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
J2SE Version (please include all output from java -version flag):
Java Web Start 10.4.1.255
Using JRE version 1.7.0_04-ea-b13 Java HotSpot(TM) Client VM


Does this problem occur on J2SE 1.5 or 6ux?  Yes / No (pick one)

No

Operating System Configuration Information (be specific):

Windows 7 Ultimate 64 bit
Intel Core 2 T5600

Hardware Configuration Information (be specific):

Launching through Firefox.  No 64 bit JVMs installed.
Connecting through Tomcat 6, with clientAuth="true"

Bug Description:

Webstart doesn't download updated jar files.  In fact, it doesn't even seem to check.
Looked at the Tomcat access log, and it is not showing any connections for most of 
the jar file.  (Probably just the eager ones work.)

Have to choose the certificate from the dialog box 2 or 3 separate times. 
(It would be nice if double-clicking an item would select it and close the dialog.) 
With a clean cache directory, only need to do this once.

touched (Solaris 'touch' command) all the files in the lib/dsi directory several 
times during this test, plus uploaded changed jar files to the webserver.  
The clientC.jar (eager) gets downloaded.  The javaws logs state that the other 
jar files in the lib/dsi directory are being checked, but these calls don't 
make it to the server.

Cleaning the cache directory seems to be the only way to get new content.

Steps to Reproduce (be specific):
More information from submitter:

Looks like it happens whether or not clientAuth is on or not.  
That is good, as it will make it easier to test.

Steps to reproduce:

1.Uninstalled all Java 7 versions from the machine

2.Installed Java 7 Update 3 (from www.oracle.com/...)

3.Clicked on file looking at Tomcat access log, and could 
  see all the files being checked. (WORKING)

4.Uninstalled Java 7 Update 3

5.Installed Java 7 update 4 ! build 13
        
6.Clicked JNLP link in Firefox while looking at the 
  Tomcat access log, and could see that NOT all the 
  files being checked. (NOT WORKING)
 

Before did the above sequence, had tried a 7U4-build 9 
that is the only installer version of on machine.  
It suffered from the same problem as build 13.

Looks like this was introduced early in the update 4 release line.

                                    

Comments
EVALUATION

Webrev: http://sa.us.oracle.com/mail-archive/7151950-deployment
Fixed: http://closedjdk.us.oracle.com/jdk8/deploy/deploy/rev/d78ffeaee1f5
                                     
2012-03-11
EVALUATION

This bug was introduced by fix to the soft references issue (CR6967414).  We wanted avoid immediate update to lazy resource in case of multiple applet sharing JVM or reloading.
The possible fix could be to check if webstart environment and check=always do not exclude lazy resources.
                                     
2012-03-08



Hardware and Software, Engineered to Work Together