Java Web Start Technology and Application Clients in the GlassFish Application Server

Print-friendly Version

Download PDF of All 4 Parts

Articles Index

Part 1 - Introduction
Part 2 - JNLP and Java Web Start Technology
Part 3 - GlassFish Application Clients: The Java Web Start Experience
Part 4 - Security, Advanced Topics, and a Look Ahead

This part of the article examines the Java Web Start experience in the GlassFish app server from the perspective of developers, administrators, and end users.

As a developer, you are probably asking what you need to do to allow your application clients to be launched using Java Web Start technology. In this section we answer that question.

Developing Application Clients for Java Web Start Access

Suppose you are building an EAR file that contains an embedded application client. Or perhaps you are writing a stand-alone application client. Here is what you need to do differently to enable Java Web Start support:

(This space intentionally left blank.)

That's right – you do not need to do anything different in writing or packaging your application to benefit from Java Web Start support. By the way, this means that any application client you might already have is ready to use Java Web Start technology.

Customizing Java Web Start Support

You can customize some things related to the Java Web Start support for a given application client by creating or adding to the sun-application-client.xml descriptor file that you package in the META-INF/ directory in your application client. (Future plans call for allowing much more customization.) The GlassFish server supports a new optional element in that descriptor, <java-web-start-access>, where you specify these customizations.

• Disabling Java Web Start access – If you do not want this application client ever to be eligible for access using Java Web Start technology, add
  
  

  <eligible>false</eligible>

   
  as a child element under <java-web-start-access>. (The administrator can also control whether an application client is enabled for Java Web Start access after it has been deployed. See the discussion below.)


• Specifying the URL – The GlassFish server automatically assigns the URL by which end users can launch each application client. If you package an application client named myClient inside an EAR named myApp, then the default URL for launching that application client is http://host:port/myApp/myClient.. If you deploy a stand-alone application client named myOtherClient, then the default URL is http://host:port/myOtherClient.
  
  To use http://host:port/drawTool to launch your client, add
  
  

  <context-root>drawTool</context-root>

   
  as a child under <java-web-start-access>.


• Affecting the download display – As the Java Web Start software downloads the JNLP and JAR files for an application, it displays a progress screen that can display the vendor of the application. By default, the GlassFish app server uses the display name from the app client's application-client.xml descriptor for the vendor name. You can control the text displayed there by adding
  
  

  <vendor>MyCorp, Inc.</vendor>

   
  as a child under <java-web-start-access>. Java Web Start software then uses its splash screen with that text – My Corp. Inc. – during downloads and launches.
  
  After the Java Web Start software has downloaded an application, it displays an icon image with that application in its catalog of downloaded applications. You can specify which icon image to use by adding an entry like the following to the vendor value:
  
  

  <vendor>images/drawtoolIcon.jpg::MyCorp,Inc.</vendor>

   
  You can also specify the splash screen image that you want the Java Web Start software to use during a launch:
  
  

  <vendor>images/drawtoolIcon.jpg::images/drawtoolSplash.jpg::MyCorp,Inc.</vendor>

   
  You can specify the splash screen image without specifying the icon image:
  
  

  <vendor>::images/drawtoolSplash.jpg::MyCorp,Inc.</vendor>

   
  For each image path, use a relative URI that points to the image within the application client module. In these examples you would have packaged the image files into the images/ subdirectory of the application client module.
  
  Entering tags like those above is not the ideal way for you to specify this information. Developers requested this enhancement, and this approach provided these customizations with minimal changes to the GlassFish source code. Future changes might allow more graceful customization of and control over the generated JNLP document.

The key point to remember about these customizations is that they are optional.

As soon as you deploy an EAR that contains an application client, the GlassFish app server supports Java Web Start access to it, provided that the developer did not specify <eligible>false</eligible> in the application client's sun-application-client.xml descriptor file. As an administrator you do not need to take any additional steps to allow end users to launch application clients using Java Web Start technology.

Note that Java EE does not require stand-alone application clients to be deployed to the server. They can be run directly using the ACC on an end-user system. But, if you want to use the GlassFish app server to provide Java Web Start access to a stand-alone application client, then you must deploy it. Otherwise the server does not know about the application client and so cannot generate the JNLP for it or serve the JARs required to run it on an end-user system.

As an administrator, you might need to deploy an application that contains an application client but for some reason you want to prohibit Java Web Start access to the application client. You can disable Java Web Start access to an otherwise eligible application client using the GlassFish asadmin utility after you have deployed the application. This saves you from having to edit the application client's sun-application-client.xml descriptor file to make the application client ineligible for Java Web Start access and then rebuild the application.

First, suppose you deploy an EAR with the name myApp containing an application client with the name myClient. You can disable the Java Web Start support for all application clients in myApp using this command:

asadmin set  domain.applications.j2ee-application.MyApp.java-web-start-enabled="false"

You can later re-enable Java Web Start access by setting the same expression to true instead. See the GlassFish Administration Guide for a full discussion of the dotted notation for referring to configuration information.

Second, suppose you deploy a stand-alone application client with the name myClient. You can turn off Java Web Start access to it using this command:

asadmin set domain.applications.appclient-module.MyClient.java-web-start-enabled="false"

Note that the administrator cannot use the asadmin set set command to make an application client accessible via Java Web Start software if the developer of the application client set <eligible>false</eligible> in the descriptor file.

After you have developed and deployed an application client, your end users should see no difference in the way the application client itself works when they launch it using Java Web Start technology. Of course, their experience launching it will be much different from what they see using the classic appclient script. However, after it has started running, an app client will behave the same regardless of how your users launch it.

Launching the Application Client

After you deploy the application containing the application client, you need to make the URL for launching the application client available to end users. You can send your users email with a link to the URL, or you can post the link on a web page, perhaps even on a web page in the same application that contains the application client.

With a single mouse click on the link, your end users will be able to download the application client along with its required JAR files and launch the application client.

You do not need to distribute any files to end-user systems yourself, either for the initial version of your client or updates. If you revise your application, you do not need to do anything other than redeploy the application to make the update available to your end users.

There are two other ways you can launch application clients. The GlassFish app server provides a graphic administration console. The console lets you navigate to any stand-alone or embedded application client that you have deployed and launch the client. This is not how you would expect most end users to start the client, but it makes it very easy to test and demonstrate the Java Web Start feature with an application client.

Also, the Java runtime provides the javaws command, which accepts the URL of the Java Web Start application you want to start. This works fine as well for launching application clients if you provide the URL for the application client. This is probably not how you will choose for most end users to start an application client, but it is useful for testing.

Monitoring Progress

An end user who launches a Java Web Start application sees a default splash screen like this:

Figure 1: Default Splash Screen

Then the Java Web Start software displays some information about the application. During the download itself, the Java Web Start software displays a progress bar, as shown here:

Figure 2: Progress Bar

The user might also see a similar screen announcing the launch of the application.

Trusting or Rejecting Certificates

Next, the user might see some dialog boxes related to security. (See the later section of this article for more information about security.) Some of the code in the application client container needs elevated permissions to do its work. To comply with the Java Web Start security rules, the GlassFish app server signs JARs that contain such code. When the Java Web Start software downloads a signed JAR, it checks to see if the certificate used to sign the JAR can be traced to a trusted certificate authority. If so, it continues loading the application silently. If not, the Java Web Start software displays a dialog box like this:

Figure 3: Security Warning Dialog Box

The end user decides whether he or she trusts the origin of the code and clicks either Run or Cancel. In general, different JARs might have been signed using different certificates and the Java Web Start software prompts the user for each untrusted certificate that was used to sign a downloaded JAR file.

If the user accepts all such certificates, then the Java Web Start software loads and starts the application client container which, in turn, starts the application client. As the user accepts a certificate he or she can tell the Java Web Start software to always trust JAR files signed by that certificate.

Using the Client

After the Java Web Start software starts the application client container (ACC), users will have the same experience with the client they have if they start it using the appclient command. The client's GUI will appear and work normally.

This is not the case if the client uses the command window for input or output because the Java Web Start software by default does not automatically display a window to contain System.out messages. Further, the Java Web Start software does not accept command window input. The advanced topic about System.out and System.err below discusses this topic in more detail.

Java Web Start File Caching

Note that the footprint of the ACC is larger than it ought to be. Several JAR files, one named appserv-rt.jar file being particularly large, must be available on the end user's system for application clients to run. The first time a user launches an application client using Java Web Start software, he or she will notice a delay while these JARs are downloaded. It can take several extra seconds over a local network and longer over a wide-area network. Keep this first-launch behavior in mind and make sure your end users – or the audience for your demo – expect this.

Because Java Web Start software caches downloaded files, subsequent launches of the same client —or launches of any client from the same GlassFish app server instance – reuse the cached copies of these JARs. This adds significant speed to later launches and leads to a much more gratifying experience.

In Part 4 of this article, you will learn about security and advanced topics, then look ahead at plans for improving the Java Web Start feature of the GlassFish app server.

• Java EE SDK — contains Sun Java System Application Server, Sun's supported distribution of GlassFish
• The Aquarium — the GlassFish Community blog
• Sun Java System Application Server page — with links to the GlassFish Community site
• Java Web Start — all about Java Web Start technology
• JSR 56 — Java Network Launching Protocol and API
• Tim Quinn's blog — focused mostly on Java Web Start support in the GlassFish application server
• Java Training and Certification — professional development to enhance your skills
• Developer Support — online incident-based programming advice, telephone product support, developer training courses, service plans
• Sun Java System Application Server Support