On Thu, Oct 16, 2008 at 11:44:59AM +0200, Niclas Hedhman wrote:
> On Wed, Oct 15, 2008 at 8:16 PM, Peter Jones <[EMAIL PROTECTED]> wrote:
>> Interesting exception trace. Do you know the actual class of the
>> java.security.Policy in effect in this JVM?
>
> Yes, I do;
> This is all to set up my automated tests (which I think is River's
> weakest point at the moment), so it is a simple inner class. It looks
> like this;
>
> // test initialization
> if( System.getSecurityManager() == null )
> {
> Policy allPolicy = new TestPolicyAllPermissions();
> Policy.setPolicy( allPolicy );
> System.setSecurityManager( new SecurityManager() );
> }
>
> // test policy
> private static class TestPolicyAllPermissions extends Policy
> {
> private Permissions permissions;
>
> private TestPolicyAllPermissions()
> {
> permissions = new Permissions();
> permissions.add( new AllPermission() );
> }
>
> public PermissionCollection getPermissions( CodeSource codeSource )
> {
> return permissions;
> }
That explains it. (And the Java 6 API change was a red herring,
although I'm glad to have learned about it anyway.) Your test Policy
implementation's getPermissions method must return a new permission
collection on every invocation, per the spec contract previously
discussed, so that each caller's mutations are isolated. As it is
above, one caller will add permissions to the collection and use it to
create a protection domain, which will cause it to be set read-only,
and then a later caller will try to add permissions to the collection,
but receiving the same collection as the previous caller, will find it
to have been set read-only, causing the the exception you reported.
-- Peter
