-
Bug
-
Resolution: Fixed
-
P2
-
7u4
-
b31
-
x86
-
windows_7
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2222348 | 7u6 | Nam Nguyen | P2 | Closed | Fixed | b03 |
JDK-2222069 | 7u4 | Nam Nguyen | P2 | Closed | Fixed | b16 |
JDK-8017340 | 6u65 | Vikram Aroskar | P2 | Closed | Fixed | b01 |
JDK-8005145 | 6u60 | Vikram Aroskar | P2 | Closed | Fixed | b01 |
JDK-8012133 | 6u43 | Vikram Aroskar | P2 | Resolved | Fixed | b60 |
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.
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.
- backported by
-
JDK-8012133 REGRESSION:Webstart in 7u4 b13 not downloading new content
-
- Resolved
-
-
JDK-2222069 REGRESSION:Webstart in 7u4 b13 not downloading new content
-
- Closed
-
-
JDK-2222348 REGRESSION:Webstart in 7u4 b13 not downloading new content
-
- Closed
-
-
JDK-8005145 REGRESSION:Webstart in 7u4 b13 not downloading new content
-
- Closed
-
-
JDK-8017340 REGRESSION:Webstart in 7u4 b13 not downloading new content
-
- Closed
-