 | |
Articles Index
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
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 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 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:
You can later re-enable Java Web Start access by setting the same expression to 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:
Note that the administrator cannot use the
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 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 Monitoring Progress An end user who launches a Java Web Start application sees a default splash screen like this:
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:
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:
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.
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
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
Note that the footprint of the ACC is larger than it ought to be. Several JAR files, one named 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. References
|
| ||||||||||||||||||||||||||||||
| |
| ||||||||||||
Print-friendly Version
