JDK-6658315 : Regression: JNLP files in subdirectories can not be launched
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u10
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-02-01
  • Updated: 2010-09-17
  • Resolved: 2008-03-28
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 6 JDK 7
6u10 b12Fixed 7Fixed
Related Reports
Relates :  
JDK-6606784 - Add support for launching applets from JNLP files
Relates :  
JDK-6659571 - PIT Exception "JavaWebStartSecurity: couldn't find JNLPClassLoaderIf" coming during HTTPS tests exec
Description
The file's base URL was used as a codebase, which is just wrong
in case of the JNLP launch through javaws.
Comments
SUGGESTED FIX Webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6658315.5/ Test Cases: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6658315/ 6658315 : Regression: JNLP files in subdirectories can not be launched [Ken Russel, Thomas Thomas.V.Ng] The precious fix was not thoroughly enough, launch was still broken. Restores the original JAVAWS resource relocation, i.e. it makes sure, neither a codebase nor a documentbase is passed from the Launch and LaunchDownload. This means no change of the LaunchDesc handling against the pre-merge version. +++ JNLP OOPP codebase handling has changed, since the previous implementation and semantic was faulty. To maintain backwards compatibility, JNLP OOPP is not allowed to overwrite absolute codepath URLs within JNLP files. We also did not respect the case, where the JNLP file is not located within the desired codebase. While deploying websites, one usually avoids absolute URL under all circumstances. This allows one to move a branch around, even to another server without the need to fix absolute URLs. This natural behavior is now available. The solution to this dilemma - still maintaining deployment convenience and JAVAWS backward compatibility, is the following logic to determine the codebase: - If the JNLP codebase is absolute, use it. - Else, use the parents codebase (either the parent JNLP, or the applet) and merge both codebases.
08-02-2008
SUGGESTED FIX The precious fix was not thoroughly enough, launch was still broken. Restores the original JAVAWS resource relocation, i.e. it makes sure, neither a codebase nor a documentbase is passed from the Launch and LaunchDownload. This means no change of the LaunchDesc handling against the pre-merge version. JNLP OOPP codebase handling has changed, since the previous implementation and semantic was faulty. To maintain backwards compatibility, JNLP OOPP is not allowed to overwrite absolute codepath URLs within JNLP files. We also did not respect the case, where the JNLP file is not located within the desired codebase. The solution to this dilemma - still maintaining deployment convenience and JAVAWS backward compatibility, is the following logic to determine the codebase: - If the JNLP codebase is absolute, use it. - Else, use the parents codebase (either the parent JNLP, or the applet) and merge both codebases. Example 1: parent: http://www.sun.com/ this: http://www.nvidia.com/test/ result: http://www.nvidia.com/test/ Example 2: parent: http://www.sun.com/ this: codebasedir result: http://www.sun.com/codebasedir Example 3: parent: http://www.sun.com/test2/ this: <null> result: http://www.sun.com/test2/
07-02-2008
EVALUATION Removing the codebase for the LaunchDescrFactory call, which is not the desired one, but a temporary in case of javaws launches.
01-02-2008
SUGGESTED FIX Removing the codebase for the LaunchDescrFactory call, which is not the desired one, but a temporary in case of javaws launches.
01-02-2008