Java Reference
In-Depth Information
L
ISTING
9.3
The install-win JNLP File
<?xml version=”1.0” encoding=”utf-8”?>
<jnlp spec=”1.0+”
codebase=”http://server/b2/c9/install-win/”>
<information>
<title>An Installer Launched via JNLP</title>
<vendor>Mauro Inc.</vendor>
<description>An Installer Launched via JNLP..</description>
</information>
<security><all-permissions/></security>
<resources>
<j2se version=”1.3+”/>
<jar href=”install-win.jar” os=”Windows”/>
</resources>
<application-desc main-class=”com.marinilli.b2.c9.InstallWin”/>
</jnlp>
There are a few things to note:
•As already said, JNLP treats this code as a typical application, not an installer. We
described it as an application in line 14.
•We need an unrestricted environment to run this example, as was requested at line 9 of
Listing 9.3. For more on security, see Chapter 10.
• Naturally, our code is platform-dependent. This can be gracefully enforced in the JNLP
file itself, saving developers the code to detect the current platform we are running on.
See Chapter 10 for a discussion of this issue and for the
resource
element in general.
• Lastly, we mentioned only one resource to make up our application, the
install-
win.jar
file at line 12. So where is our native installer? In this case, we have two
choices. We can download it by ourselves from our remote server; or we can put it in our
only JAR, so that the JNLP Client will do the delivery for us. We followed the latter
solution in this example. One could imagine to look where the JNLP Client caches files
and access it from there, but it would be a useless complication because we must always
wrap resources in a JAR file, anyway, in order to let them be handled by the JNLP
Client.
The native executable has been kept to a minimal size. Probably one of the barest batch files
ever is listed in Listing 9.4. Of course, you can substitute it with your
.exe
file,
.sh
for Unix,
and so on.
