<AWT Dev> Reviewer needed - fix for regression test java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest

Pavel Tisnovsky ptisnovs at redhat.com
Thu Dec 2 04:26:32 PST 2010

Anthony Petrov wrote:
> On 12/1/2010 6:37 PM, Pavel Tisnovsky wrote:
>> Anthony Petrov wrote:
>>> Hi Pavel,
>>> On 12/1/2010 4:09 PM, Pavel Tisnovsky wrote:
>>>> can anyone please review fix for regression test
>>>> java/awt/Insets/WindowWithWarningTest/WindowWithWarning?
>>>> Webrev containing the fix is available at
>>>> http://cr.openjdk.java.net/~ptisnovs/WindowWithWarning/
>>>> Brief description of the fix:
>>>> This test must be run in an environment similar to sandbox used for
>>>> running regular applets, which among other things means that each
>>>> window
>>>> created by the test itself has to be labelled by warning message "Java
>>>> Applet Window".
>>>> But for this test to proceed it is also required
>>>> that AWT Robot is enabled (and it is disabled by default for applets,
>>>> which is reasonable, of course).
>>>> To guarantee both conditions to run this test, I created new security
>>>> policy file containing option to enable AWT robot and then configured
>>>> the test itself to use this policy file, because JTreg harness usually
>>>> starts such tests (applets) without security manager installed.
>>> Right. That's why the test installs a custom security manager in its
>>> code.
>>> Could you please explain benefits of a separate .policy file over the
>>> current approach of setting the security manager directly in the test
>>> code?
>> Hi Anthony,
>> when the test calls System.setSecurityManager( new SecurityManager()
>> {...} ) then the new security manager is installed, but this kind of
>> security manager deny the AWT robot because it is the standard behaviour
>> of applets (users usually don't want the applet to control theirs mouse
>> and keyboard).
> By default there's no any security policy present, and as such the
> default implementation of the SecurityManager permits everything. We
> override the checkTopLevelWindow() specifically to make AWT think
> there's no toplevelwindow permission present. However, all the rest of
> the permissions (including the AWT robot one) must be granted.
> If that is not the case, I believe your testing environment picks up
> some customized security policy which disallows everything by default.
> Could you verify that please?

Hi Anthony,

It seems that my testing environment (its patched JTreg harness 4.0 from
IcedTea6) uses restricting security manager for test which are started
as applets, but only after I explicitly install the manager in the test

I tried the following: the test is still started as applet (using html
file containing JTreg tags and options) but I simplified it to just four

System.setSecurityManager(new SecurityManager());

Here are result, it's copy & paste from .jtr file generated by JTreg
harness with added comments which begins and ends with ***:

command: applet WindowWithWarningTest.html
reason: User specified action: run applet WindowWithWarningTest.html
elapsed time (seconds): 0.59
*** the first line of test: security manager is not installed yet ***
*** the third line of test: now the security manager is installed ***
java.lang.SecurityManager at 77f297e7
*** statement on fourth line throws exception - it's not possible to
create AWT robot after the security manager is installed ***
java.security.AccessControlException: access denied
(java.awt.AWTPermission crea        at
     at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at WindowWithWarningTest.start(WindowWithWarningTest.java:98)
        at java.lang.Thread.run(Thread.java:636)
STATUS:Failed.Applet thread threw exception:
result: Failed. Execution failed: Applet thread threw exception:

best regards

More information about the awt-dev mailing list