It's not clear exactly why this is not working, but I can explain what the
system is trying to do. Because Java Web Start enforces strict security
(because the apps it launches are downloaded over the network) GlassFish
automatically signs the JARs used for launching app clients using Java Web
Start. In GlassFish 2.1.1 it does this by, basically, running the jarsigner
utility. (It does not really create another OS process and run that command,
but it uses the same code.) The jarsigner utility is complaining that it
cannot locate the (unsigned) generated app client JAR file to sign it for use
in Java Web Start. (One of the early log messages you posted from the
server.log file identifies the exact file.) (Do not worry about the security
errors about the System.exit calls. The jarsigner code invokes System.exit if
it detects an error. We do not want the entire server to exit if the
jarsigner fails to sign a JAR as it does in your example, so the server traps
the attempt to invoke System.exit by using a security manager for just the
jarsigner call that prohibits System.exit calls.) Here is one possible cause.
Back in the 2.x days, the app client JAR was generated asynchronously if
possible, to allow the deployment itself to be reported as completed more
quickly so the admin user could continue working sooner. It's possible that
the async generation of the app client JAR has not completed by the time the
system is trying to sign the JAR. IIRC the app client JAR generation is
synchronous if the deploy command specifies "--retrieve localdir" so you
might try that - even though you do not really need the retrieved JAR itself
- and see if that helps. Let us know. By the way, do you have plans to move
to 3.x soon? Deployment and client generation have changed moving from 2.x to
3.x and this problem should not appear in 3.x. - Tim
--
[Message sent by forum member 'tjquinn']
View Post: http://forums.java.net/node/889421