Before reviewing your security privileges, make sure that you have configured Silk Test Classic Java support.
Policy.provider = sun.security.provider.PolicyFilewhich means that the standard policy file should be used. The standard policy file, java.policy, is located in the same folder, JRE/lib/security. It contains the following code that gives all necessary permission to any file located in lib\ext directory:
// Standard extensions get all permissions by default grant codeBase "file:${java.home}/lib/ext/*"{permission java.security.AllPermission;};
Silk Test Classic has the necessary privileges, if the SilkTest_Java3.jar file is in this directory and the JVM runs with the default set of security permissions.
java _Djava.security.policy=Myown.policy MyApp
grant codeBase "file:${java.home}/lib/ext/*"{permission java.security.AllPermission;};
The default java.policy may also be changed implicitly, for example, when the application uses an RMI server with the custom RMISecurityManager and the client security policy. In cases like these, the client security policy should grant all required permissions to Silk Test Classic by including the code listed above.
In some cases, setting these permissions may not provide Silk Test Classic with the necessary security privileges. The cause of the problem may be that permissions are frame specific. So if Silk Test Classic runs in the context of frames (thread) in which it does not have the necessary permissions, it may fail. In cases like this in which the client does not trust code running in the context of the AWT event thread, you need to set the parameter ThreadSafe=False in the javaex.ini in the <Silk Test installation>/extend directory. This prevents the Silk Test Classic Java code from running in the context of the AWT event thread, preserving permissions granted to Silk Test Classic, but could make the GUI less responsive.