JDK-6740523 : DnD: should pick up codebase automatically for relaunches of dragged-out JNLP applets
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-08-22
  • Updated: 2010-09-08
  • Resolved: 2008-10-02
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.
6u10 b33Fixed 7Fixed
Related Reports
Relates :  
Currently the new Java Plug-In can infer the codebase for JNLP-launched applets, allowing the developer to not specify it at all to maintain portability of their JNLP file and its associated resources. This is similar to functionality the JnlpDownloadServlet provides for Java Web Start applications with the $$codebase and other macros.

However, when such an applet is dragged out of the browser and relaunched from a desktop shortcut, the JNLP client does not know how to re-infer the original codebase. This means that any JNLP applet that the developer wants to drag out of the browser and relaunch from a desktop shortcut must have an absolute codebase, which is undesirable.

We should use the codebase, now stored in the LocalApplicationProperties with the fix for 6732975, to begin the re-launch process for such applets.

SUGGESTED FIX testcase: http://web-east.east.sun.com/www/tests/1.6.0_10/6740523/

SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6740523.1

EVALUATION Problem: a dragged-out JNLP applet cannot be relaunched if the codebase isn't specified in the JNLP file. Fix: with the fix for 6740228, we're storing the codebase and documentbase into the LocalApplicationProperties (lap). For this fix, in JNLP2Viewer, we're obtaining the codebase and documentbase from the lap before instantiating the JNLP2Manager which instantiates the LaunchDesc. The lap is now obtained from the cache. This eliminates the dependency on LaunchDesc. In launcher.c, we no longer prepend the file protocol (file:///) to the cached JNLP filename. Instead, the file protocol will be prepended to the cached JNLP filename in JNLP2Viewer if needed.