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

[Dr Andrew John Hughes]

On 11:47 Thu 02 Dec     , Joe Darcy wrote:
> 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
> 

We'd have upgraded a long time ago if it was trivial enough.

As I think I've mentioned before on this list, getting JTreg in a state where
we can build it in IcedTea is a bit of a nightmare; see
http://icedtea.classpath.org/hg/icedtea6/raw-file/tip/test/jtreg/README for more
details.

If Oracle could do a source code release of jtreg with less dependencies,
we'd probably see much quicker adoption.  As is, someone has to pick through
and fix things (especially those dependencies like javax.comm that remain
proprietary AFAIK).

And before someone mentions it, no, we can't just use binary blobs.  Even without
regard to the license, distros require source.

BTW, I saw your mail online hours ago but it only just hit my inbox.  Any idea
what's with that?

Thanks,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8