Could Not Locate Resource
Could Not Locate Requested Version
Unsupported Operating System
Unsupported JRE Version
Checking for New Versions
As we know from Chapter 9, “The JNLP Protocol,” an application can be registered for
updates by specifying the URL where the main JNLP file can be found using the href attribute
of the jnlp element.
In this case, the JNLP client uses the last-modified field of the HTTP header of the refer-
enced file to discover new versions of the same application, even if the JNLP main file didn't
In this way, simply “touching” (that is, refreshing the last-modified file attribute of) the
JNLP main file for that application, developers may indicate to remote clients that a new
release has been published. This phase is what we called the Publication phase, in the abstract
model of Chapter 2. As an example, see Figure 2.5.
Extension Download Protocol
JNLP clients can request extensions (that are either JREs or JNLP extensions, as described in
Chapter 9) to the server. In this case, a special type of the version-based download protocol is
For example, the following snippet of JNLP file:
<resources os=”Windows” locale=”de”>
<extension name=”ext1” href=”http://www.site.com/ext1.jnlp” version=”1.2” />
will cause the JNLP client to issue the following request to the server:
We assumed that on the client machine there are two JREs already installed, with versions
1.3.1 and 1.4 .