Java Reference
In-Depth Information
Error Code
Description
10
Could Not Locate Resource
11
Could Not Locate Requested Version
20
Unsupported Operating System
21
Unsupported Architecture
22
Unsupported Locale
23
Unsupported JRE Version
99
Unknown error
12
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
change.
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
used.
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” />
</resources>
will cause the JNLP client to issue the following request to the server:
http://www.site.com/ext1.jnlp?arch=x86&os=Windows&locale=de&version-
id=1.2&known-platforms=1.3.1+1.4
We assumed that on the client machine there are two JREs already installed, with versions
1.3.1
and
1.4
.
