JDK-6866509 : codebase in JNLP file for Java Web Start applications should be optional
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u17
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-07-29
  • Updated: 2010-09-16
  • Resolved: 2009-12-01
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
6u18 b03Fixed 7Fixed
Description
Currently, it is required that you specify the codebase in the JNLP file of your Java Web Start application.

This is because Java Web Start is registered as helper application of the web browser.  When someone clicked on a jnlp link in the web browser, the browser download the jnlp file into it's temp directory, and then simply invoke java web start to handle the file.

From that point on, the only information for java web start to continue to download the rest of the application comes from the jnlp file.  that's why we need the codebase specified in the jnlp file.

However, this is not user friendly for deployer, especially when they need to move the application from one server to another.  the codebase in the jnlp file needs to be changed manually also.

it would be a big win if we can make the codebase requirement optional for java web start application's jnlp file.

this is requested by both internal and external customers.

http://weblogs.java.net/blog/kohsuke/archive/2009/07/why_cant_we_get.html
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u18/6866509.1
22-09-2009
EVALUATION Problem: Until now, the <codebase> is a required field for Java Web Start application's JNLP file. This is not user friendly, especially when you need to move the application around different servers for development/testing/deployment, because you will need to modify the JNLP file codebase manually. The JNLPDownloadServlet solves this problem by allowing $$codebase, but it requires a servlet running on the server, and many times application deployer has not much control on the server side. Also, JNLP applets running in browser with the new plugin does not have this codebase requirement anymore. Fix: To fix this, we need to introduce two new API in the deployment toolkit: launchWebStartApplication(jnlp): launch the jnlp application (for you to use in a href link or create a customzied button) createWebStartLaunchButtonEx(jnlp): create default webstart launch button for you to click and launch the application jnlp is argument to the application jnlp file. it's relative path. Both calls will basically check and make sure 6u18+ is installed, and then launch the JNLP application. On windows, it will perform auto-install if necessary. On UNIX, there is no auto-install, so we will prompt user to upgrade to latest Java. If we have 6u18+ installed, these will generate the correct OBJECT or EMBED tag accordingly. The OBJECT/EMBED tag contains the plugin CLSID/mimetype, plus the docbase of the jnlp file, obtained using javascript document.URI or document.URL, and passed in as attribue "docbase". It also pass in the jnlp file as value for attribute "launchjnlp". This will trigger browser to load the plugin ActiveX control / Firefox plugin. We modified the plugin to detect the launchjnlp param, and if that's detected together with docbase, we will simply invoke javaws with -docbase <docbase url> <jnlp>, and then exit. The browser will not initialize any JVM or plugin code at all. With this, Java Web Start can then figure out the codebase of the jnlp file, and continue to launch with the no-codebase jnlp file. We will also save the derived codebaes to the application LAP, so we can use it to launch when starting from cache. This is similar to how plugin2 support the no-codebase jnlp applet. In order for no-codebase JNLP file to work when launching from browser, deployer must use the above two new deployment toolkit APIs. Launching via command line (either with URL or local path) will work right the way with this change. Java Web Start will figure out the relative codebase if needed.
22-09-2009
EVALUATION it should be noted that for browser based JNLP applets for the new plugin starting in 6u10, these applet JNLP file do not need to have codebase specified. the new plugin gets the codebase from the browser.
29-07-2009
EVALUATION need to investigate for 6u17
29-07-2009