Archived
This forum has been archived. Please start a new discussion on GitHub.
Applet has java.lang.Runtime.addShutdownHook exception - want to avoid ICE setup
in Help Center
Hello,
Applet failure I call my method Z.createConnection and I will get an exception with "java.lang.Runtime.addShutdownHook". This is all realted to java.security.AccessControlException: access denied (java.lang.RuntimePermission shutdownHooks) which is triggered by an Ice call.
Is there any way to disable the shutdown hook setup? ( note - signing the JAR or using JNLP is not an option for me ).
Do I have to hack the code or is there some method to call to prevent the Ice.Application.changeHook(...) call.
I get the following message:
Thanks in Advance
Jon
Applet failure I call my method Z.createConnection and I will get an exception with "java.lang.Runtime.addShutdownHook". This is all realted to java.security.AccessControlException: access denied (java.lang.RuntimePermission shutdownHooks) which is triggered by an Ice call.
Is there any way to disable the shutdown hook setup? ( note - signing the JAR or using JNLP is not an option for me ).
Do I have to hack the code or is there some method to call to prevent the Ice.Application.changeHook(...) call.
public class Z extends Ice.Application { public void createConnection() { String[] custArgs = new String[7]; custArgs[0] = "--Ice.MessageSizeMax=16384"; // 16 mega-bytes custArgs[1] = "--Ice.BatchAutoFlush=1"; custArgs[2] = "--Ice.ACM.Client=0"; custArgs[3] = "--Ice.ThreadPool.Client.Size=1"; custArgs[4] = "--Ice.ThreadPool.Client.SizeMax=15"; custArgs[5] = "--Ice.ThreadPool.Server.Size=1"; custArgs[6] = "--Ice.ThreadPool.Server.SizeMax=15"; int status = main("CROME", custArgs); } }
I get the following message:
network: Connecting [url]http://binky.quantumsi.com/jbin/Zcheck?cmd=header[/url] with cookie "__utma=121695755.852096886.1270944348.1270944348.1270944348.1" !! 6/6/11 16:29:04:074 CROME: error: Thread-18: unknown exception: java.security.AccessControlException: access denied (java.lang.RuntimePermission shutdownHooks) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.Runtime.addShutdownHook(Unknown Source) at Ice.Application.changeHook(Application.java:498) at Ice.Application.destroyOnInterrupt(Application.java:348) at Ice.Application.doMain(Application.java:197) at Ice.Application.main(Application.java:180) at Ice.Application.main(Application.java:71) at Z.createConnection(BRXE) at Z.init(BRXE) at Zmain.run(BRXE)
Thanks in Advance
Jon
0
Comments
-
You can call the overload of Application that receive a SignalPolicy with SignalPolicy.NoSignalHandling this will avoid the setup of the shutdown hook. But Ice.Application isn't interesting for Applets as isn't designed to work with the applet life cycle "start/init/stop/destroy".
For a complete applet demo see java/demo/Ice/applet in Ice distribution. This demo shows how to integrate the Ice run time, with the applet life cycle.0 -
Thanks xdm,
The below seems to have worked for me, e.g. using Ice.Application with a basic Appletimport Ice.SignalPolicy; public class Z extends Ice.Application { public Z() { // Do this only if using an unsigned applet, JNLP and signed applets // can and should handle a shutdown hook. Since this mode is // "read-only' I am not concerned about 'bad' items like file // and/or database corruption. super(SignalPolicy.NoSignalHandling); } // other code/methods removed here .... }
The overload of Application that receive a SignalPolicy with SignalPolicy.NoSignalHandling did avoid the shutdown hook issue.
I understand your comment But Ice.Application isn't interesting for Applets as isn't designed to work with the applet life cycle "start/init/stop/destroy". but this solved an immediate issue with minimal code changes.
As per your direction I will inspect the applet demo see java/demo/Ice/applet in Ice distribution which you state shows how to integrate the Ice run time, with the applet life cycle. IMHO I think this will be much more inline with my intended use case.
Thanks for the prompt pointer to the solution
Jon S.0