Name: gm110360 Date: 08/18/2003


FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

FULL OPERATING SYSTEM VERSION : Windows 2000 SP2
ADDITIONAL OPERATING SYSTEMS : Generic (API/spec issue)



A DESCRIPTION OF THE PROBLEM :
The JNLP API documentation for DownloadService only manages
parts and extensions which are "mentioned in the JNLP file
for the application". Similarly, in JSR-56 (v1.0.1), pg 46
(and similar wording elsewhere), "The methods must always
fail for resources that do not belong to the current
application, i.e., are not mentioned in the JNLP file for
the application." It may be that there is a very compelling
rationale for this decision but, in my reading, I have not
encountered it.

If I am writing an app that supports dynamically installable
"plug-ins", I would like to do that via JWS -- without
having to write a new JNLP file for each permutation of
application modules. Example: NetBeans IDE.

The way I would want this to work is as follows:

1. An application which requires "dynamic plug-in
downloading" should declare this in its JNLP file.

2. The application is responsible for determining the sets
of URLs it wishes to download through a source outside JWS.
For example, it could connect to "modules.myapp.com" to get
a list of available modules.

3. The application then downloads and manages these
resources via the DownloadService, with no restriction that
they are in the application's JNLP file.

4. The application is responsible for calling some
well-known class downloaded by the extension; this will
probably mean that the extension's JNLP file should contain
information about that. Again, this is to be
application-specific.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
1. At modules.myapp.com, provide a servlet which returns JWS
applications, complete with JNLP files.

2. Encapsulate as much as possible of the application in
extensions; this means that the root (application) contains
no [appreciable] code or resources.

3. On the modules.myapp.com website, provide a set of HTML
screens that give a user a chance to select which modules
they wish to include. At the end of this process, they get a
Web page with a "Run my app now" button. This returns them
their custom JNLP file with their selected modules.

4. Encode into the URL of the user's JNLP file their choice
of modules. This way, when the URL is reloaded, a compatible
JNLP file is returned every time --

  modules.myapp.com/app.jnlp?modules=base,text,mpeg,email

5. Each new choice of modules will generate a new JNLP file
for the application, but the extensions (= modules)
themselves will be re-used from one to the other choice.
(Incident Review ID: 179439)
======================================================================