db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-892) add mechanism for specifying policy file for individual function tests
Date Sun, 14 May 2006 15:53:06 GMT
    [ 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
-  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:
>     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:
For more information on JIRA, see:

View raw message