Oddly enough, in the test that passes, I don't see the implies call for
DownloadPermission
Peter Firmstone wrote:
Hi,
Got an interesting concurrency bug to solve, if you check out the
latest revision, you can simulate this bug. Go back to rev 981386,
the bug isn't apparent.
Basically the changes are:
DynamicConcurrentPolicyProvider:
implies(ProtectionDomain, Permission)
old version calls underlying basePolicy.implies() first, then
basePolicy.getPermissions()
new version skips implies and calls basePolicy.getPermissions()
grant( Class ...)
Changed to use AccessController.checkPermission() instead of
SecurityManager call of same name.
Only implies() is involved in this case.
The test in question:
com/sun/jini/test/spec/loader/pref/preferredClassLoader/GetPermissionsSecurityException.td
The 7 tests that fail are related to PreferredPolicyProvider, no
DynamicPolicy tests fail.
The reason the basedPolicy.implies() is no longer called is to remove
the possiblity of a ConcurrentModificationException that would occur
when an implies from a concurrent thread causes UnresolvedPermission's
to become resolved, changing underlying state during an Enumeration.
Oh and the test passes when -Djava.security.debug=access:failure is used.
Test results attached.
I'll commit a changed to the build.xml file for qa, so you can run the
test from the qa directory using ant run-tests
Cheers,
Peter.
