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

[Joe Darcy]

Pavel Tisnovsky wrote:
> Anthony Petrov wrote:
>   
>> Hi Pavel,
>>
>> On 12/02/2010 03:26 PM, Pavel Tisnovsky wrote:
>>     
>>>>>> Could you please explain benefits of a separate .policy file over the
>>>>>> current approach of setting the security manager directly in the test
>>>>>> code?
>>>>>>             
>>>>> 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
>>> itself.
>>>
>>> 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
>>> lines:
>>>
>>> System.out.println(System.getSecurityManager());
>>> System.setSecurityManager(new SecurityManager());
>>> System.out.println(System.getSecurityManager());
>>> System.getSecurityManager().checkPermission(new
>>> AWTPermission("createRobot"));
>>>
>>> Here are result, it's copy & paste from .jtr file generated by JTreg
>>> harness with added comments which begins and ends with ***:
>>>
>>> ----------messages:(3/142)----------
>>> command: applet WindowWithWarningTest.html
>>> reason: User specified action: run applet WindowWithWarningTest.html
>>> elapsed time (seconds): 0.59
>>> ----------System.out:(2/40)----------
>>> *** the first line of test: security manager is not installed yet ***
>>> null
>>> *** 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 ***
>>> ----------System.err:(8/650)----------
>>> java.security.AccessControlException: access denied
>>> (java.awt.AWTPermission crea        at
>>> java.security.AccessControlContext.checkPermission(AccessControlConte
>>>         at
>>> java.security.AccessController.checkPermission(AccessController.java:
>>>      at
>>> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>>>         at WindowWithWarningTest.start(WindowWithWarningTest.java:98)
>>>         at
>>> com.sun.javatest.regtest.AppletWrapper$AppletRunnable.run(AppletWrapp
>>>         at java.lang.Thread.run(Thread.java:636)
>>> STATUS:Failed.Applet thread threw exception:
>>> java.security.AccessControlExceptio
>>> result: Failed. Execution failed: Applet thread threw exception:
>>> java.security.A
>>>       
>> Looks like this is a problem with your patched IcedTea jtreg harness
>> rather than with the test itself then.
>>     
>
> The same behaviour could be also reported on unpatched JTreg Harness 4.0.
>
> (so it's just another reason to update JTreg harness to 4.1 on IcedTea6 ;)
>   

Yes, I've been happily using jtreg 4.1 since it was released earlier 
this year and my published OpenJDK 6 regression test results since them 
have used this version of jtreg.

-Joe