[ 
http://issues.apache.org/jira/browse/DERBY-892?page=comments#action_12402218 ] 

Myrna van Lunteren commented on DERBY-892:
------------------------------------------

I looked at the pre-patch, running the test derbynet/sysinfo.java and it seems 
to me this is a good step.

However, the calls to updatePolicyFile() method were too late for 
networkserver, which is the relevant place for the sysinfo test which had 
securityManager switched off.

The new patch (DERBY-892_20060514.*) differs from the prepatch by Andrew in the 
following ways:
-  removes the CopySuppFiles(..., <policyfile>) from jvm.java and adds it to 
updatePolicyFile() in RunTest.java.
- renames updatePolicyFile() to composePolicyFile()) (because it no longer just 
updates the policy file)
- calls the updatePolicyFile() method before starting networkserver, as well as 
in both the execTestNoProcess and ExecTestProcess methods
- adjusts the sysinfo.policy file to:
   . add a semi-colon after } for each codeBase section
   . grants the same permissions as are currently in derby_tests.policy for 
DERBY-622, rather than the derbyLocale jar read grants.
(Granting read permissions for the locales did not work for me - I assumed 
there was more needed that related to a fix for DERBY-622 than was in the 
pre-patch).
- removed derbynet/sysinfo_app.properties' restriction to not run the client 
side with security manager by adding the following permission to sysinfo.policy:
   grant codeBase "${derbyTesting.codejar}derbyTesting.jar" {
      permission java.io.FilePermission "<<ALL FILES>>", "execute";
   };
   and same to ${derbyTesting.codeclasses}.
   Note: the sysinfo_app.properties file suggested read permission, but that 
gave an error indicating execute was needed, and that made sense to me
- stripped derby_tests.policy of permissions for specific tests:
   . sysinfo and sysinfo_withproperties
   . secureUsers1.sql
   . NSinSameJVM:
   . derbynet/getCurrentProperties.java
   . lang/errorStream.java:  
- After running derbyall, I found the permissions for errorStream.java 
(setIO)were also required for derybnet/dataSourcePermissions_net, testSecMec 
and OutBufferedStream, so I created policy files for those tests too.
- Following Andrew's example in previous commits I eliminated the need for 
changing copyfiles.ant in tests/lang
- I added *.policy to the build.xml files in the test directories where I added 
one (or more).


> add mechanism for specifying policy file for individual function tests
> ----------------------------------------------------------------------
>
>          Key: DERBY-892
>          URL: http://issues.apache.org/jira/browse/DERBY-892
>      Project: Derby
>         Type: Bug

>   Components: Test
>     Versions: 10.2.0.0
>     Reporter: Myrna van Lunteren
>     Priority: Minor
>  Attachments: DERBY-892_20060514.diff, DERBY-892_20060514.stat, 
> derby-892_pre.diff
>
> It would be nice to be able to specify a test-specific policy file.
> This should get handled similar to existing properties, i.e. get specified in 
> a test_app.properties file (or, for a suite, in the suite.properties file).  
> The file should then be copied into the correct place.
> Note, that the 'old' functionTests harness (as opposed to junit tests) 
> includes a check for a property called 'serverPolicyFile' (in 
> harness/jvm.java). The name is a left over from when the policy file was only 
> used for/by network server, and should be renamed - derbyTestPolicyFile, for 
> instance. It is not used anywhere at present, and not specific to network 
> server. It would be nice if this could be expanded, or, if not used, removed.
> The default policy file used is the derby_tests.policy file under 
> functionTests/util.
> Also, currently, the property can only be used with RunTest - for further 
> traction, it should probably get passed on through RunSuite/RunList.
> Once confirmed to be working, the property should get documented in 
> <trunk>/java/testing/README.htm.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to