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

Joe Darcy joe.darcy at oracle.com
Thu Dec 2 11:47:14 PST 2010

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.


More information about the distro-pkg-dev mailing list