Fixed in 3.0.1 via the commit below (and in 3.1 in the commit described in a
later update to this issue).
Note that this fix will cause GlassFish to create signed copies of the GlassFish
JARs which are used during Java Web Start launches. These signed JARs are
created when GlassFish first receives a Java Web Start request for them. This
means that the first user who launches a client using Java Web Start after a new
GlassFish installation might see a longer-than-usual delay while GlassFish
creates the signed copies of the JARs. But once any Java Web Start launch
occurs, the signed copies of the JARs will be used for any Java Web Start launch
of any application from any user.
By default, the copies will be signed using the domain's self-signed certificate
with alias s1as. If the user specified the optional jar-signing-alias property
while deploying an app, then GlassFish will create separate copies of the
required GlassFish JARs using that alias. Again, the same copy will be shared
across all apps deployed with that jar-signing-alias and across all users
launching those apps.
Because the JARs downloaded are signed, Java Web Start on the client will take
some additional time to verify these JARs before using them, as happens whenever
a signed JAR opened. Note that this verification will occur each time a user
launches an app, even if the locally cached copies of the GlassFish system JARs
Date: 2010-05-20 15:00:10+0000
New Revision: 37116