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.
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.