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.
|
|
|
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/
|
|
|
SUGGESTED FIX
Removing the codebase for the LaunchDescrFactory call,
which is not the desired one, but a temporary in case of javaws launches.
|
|
|
EVALUATION
Removing the codebase for the LaunchDescrFactory call,
which is not the desired one, but a temporary in case of javaws launches.
|
|
|
|
Java