Hi Joe and Daniel Thank you very much for your suggestions! Now I fully understand the rule(at least I think so :P) I will use a runWithAllPerm block surrounding the user setup code as Daniel's way. Btw, Daniel, ThreadLocal should not need Atomic any more, correct?
Frank > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fu...@oracle.com] > Sent: Tuesday, July 26, 2016 8:47 AM > To: huizhe wang; Frank Yuan > Cc: 'Amy Lu'; 'core-libs-dev' > Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit > tests > > On 26/07/16 00:53, huizhe wang wrote: > > To avoid having to grant the permission, the test may choose to read the > > property before setting the SecurityManager. You might not be able to > > use TestNG Listeners in such case, or maybe you can by initializing the > > properties before the test starts. > > Or you can use my trick with an AtomicBoolean for such cases: > > set allowAll to true > try { > read system property > } finally { > set allowAll to false (or to the value it had before) > } > > Adding a ThreadLocal<AtomicBoolean> allowAll to BasePolicy > for that purpose is very easy :-) > > That should ensure that you only need to give those permissions > to the test that a regular user of the JAXP API would need to > use the JAXP API. > > If the test read/writes an XML document from file, then the > FilePermission to read/write that document is something that > a regular user of JAXP would need. So those permission should > be granted to the test through Policy. > > If the test reads/writes a system property or creates a directory > or create a class loader to set up an initial configuration for > the test to run, then this is not something a regular user of the > JAXP API would need - so it would then be legitimate to perform this > setup inside a block that sets allowAll to true to locally escape > permissions checks during this setup, thus avoiding to grant those > permissions to all in the Policy (alternatively you could use your > tmpPermissions trick to do that as well - but it is a bit more > complex and adds more clutter than a simple on/off switch). > > cheers, > > -- daniel
