Signed JARs (again), app clients, and Java Web Start

Some of the details of the Java Web Start support in GlassFish have changed. You can still launch any app client you deploy using Java Web Start, so that this outward behavior has not changed. But what happens inside the app server has evolved, and you have some new options for controlling some of that processing.

Basically, we are trying to help end-users protect themselves even more vigorously from the risks of downloading programs over the network, which is after all what the Java Web Start feature of GlassFish does. Very briefly, two types of jar files downloaded via Java Web Start from the app server are now always delivered in signed form:

  • the appserv-jwsacc.jar (which contains key parts of the app client container that actually executes an app client), and

  • the generated app client jar files (which contain the contents of the original app client jar from the developer plus some additional information needed to run the client correctly).

The app server will sign them automatically for you using a self-signed certificate that is created any time you create a new app server domain. This auto-signing behavior is very convenient in a development environment since it requires you to do no additional set-up. But the default auto-signing behavior it is not very secure, because anyone can create a self-signed cert claiming to be anyone. In fact, this is why Java Web Start warns you, when it downloads a jar signed with a self-signed certificate, that the cert is invalid. The end-user can still choose to run the downloaded code, but at his or her own risk.

If you have your own certificate, you can arrange for the app server to use it instead of the domain's self-signed certificate in this auto-signing mechanism. If your certificate is in a trusted chain to a certificate authority, then your end-users can be much more confident that the code is trustworthy.

In either case, the auto-signing behavior signs every jar file with the same cert. If you want to, you can manually sign individual jars with different certs.

The steps to trigger the non-default behavior – either to have the app server auto-sign the jars with your cert or for you to sign the jars manually – are actually fairly simple, but there's some important background information that you'd need. I have written up this rough document that tries to explain this. The content will probably form the basis for the product documentation for this aspect of the Java Web Start feature, so I would very much appreciate any feedback people have on the description as well as the feature itself. I already know of several ways in which I would like to improve the overall process, but I'd love to hear what others have to say.

GlassFish Java Web Start


Thanks for your excelent blog! You solve a lot of my troubles, but one thing continuos a bug me. Glassfish only recognizes the static methods on the main class? Example: I have 2 classes, the first class is my main class, if a use @EJB on the second class Glassfish don't create de references in application-client.xml and a NPE happens.

Posted by Augusto Cesar Righetto on April 24, 2006 at 11:24 AM CDT #

The Java EE spec states that the app client container must inject into static elements of the main class but not other classes. The GlassFish implementation does exactly this. So you may need to slightly change your client code so all injected resources are defined as static elements on the main class.

Posted by Tim Quinn on April 25, 2006 at 01:40 PM CDT #

Hi, great work with Web Start in Glassfish and great blog about it! However I couldn´t make it work with Mustang. Have you tried it? It works perfect with Java 5 but with 6 it doesn´t load my application client. Please e-mail me if you have any information about this problem. Thanks.

Posted by Ignacio Goyeneche on May 09, 2006 at 12:02 AM CDT #

Thanks for your kind words about the Java Web Start support. We are aware of the problem with Mustang and we will be looking into it in detail very shortly.

Posted by Tim Quinn on May 14, 2006 at 11:32 PM CDT #

Just to bring these comments up-to-date... Changes have been checked in to GlassFish so that the Java Web Start launching feature now works with both JDK 5 and JDK 6.

Posted by Tim Quinn on August 16, 2006 at 01:52 AM CDT #

Post a Comment:
  • HTML Syntax: NOT allowed

News and musings on the technology I work on at Oracle.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« June 2016