Interesting exception trace.  Do you know the actual class of the
java.security.Policy in effect in this JVM?

The RMIClassLoader implementation (the default implementation as well
as net.jini.loader.pref.PreferredClassProvider) assumes that it can
add arbitrary permissions to the PermissionCollection returned by an
invocation of getPermissions(CodeSource) on the Policy in effect--
i.e. that this PermissionCollection will not have been set read-only.

With J2SE 5.0 and earlier, that was a reasonable assumption, as the
@return specification for that method, which was abstract in
java.security.Policy, included this contract:

    The returned set of permissions must be a new mutable instance and
    it must support heterogeneous Permission types.

But in Java SE 6, the Policy.getPermissions(CodeSource) spec was
changed to allow the implementation to "not support" the operation, in
which case it is specified to return a singleton (?) read-only empty
PermissionCollection-- and the method was made non-abstract, with the
default implementation carrying out this "not supported" mode.  A
Policy that implements this mode breaks the above-mentioned assumption
in the RMIClassLoader implementation and would cause the exception in
the trace below.  I was not previously aware of this change in Java 6,
and I must say that I find it rather surprising (the breaking of the
mutability contract).

The Sun JDK's default Policy implementation
(sun.security.provider.PolicyFile) still implements (now overrides)
getPermissions(CodeSource) to return a new mutable collection as
before, so with the default policy, or another that wraps it, this
problem would not be noticed-- it would only seem to be noticed when
using a Policy implementation written for the Java 6 API.

-- Peter


On Mon, Oct 13, 2008 at 12:44:14AM +0800, Niclas Hedhman wrote:
> I am getting the exception below when my testcases tries to run
> against a Transient Reggie using JERI (well, same result with JRMP),
> that I have started.
> 
> I suspect that this related to the jsk-policy.jar not being in the
> lib/ext. But I need this to work without modifying the JVM
> installations... What choices do I have?
> 
> Cheers
> Niclas
> 
> INFO: exception occurred during unicast discovery to
> f053112108.adsl.alicedsl.de:55413 with constraints
> InvocationConstraints[reqs: {}, prefs: {}]
> com.sun.jini.discovery.DiscoveryProtocolException
>       at 
> com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery(DiscoveryV1.java:419)
>       at net.jini.discovery.LookupDiscovery$13.run(LookupDiscovery.java:3327)
>       at 
> com.sun.jini.start.AggregatePolicyProvider$6.run(AggregatePolicyProvider.java:527)
>       at java.security.AccessController.doPrivileged(Native Method)
>       at 
> net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3324)
>       at 
> net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3355)
>       at 
> net.jini.discovery.LookupDiscovery.access$3900(LookupDiscovery.java:696)
>       at 
> net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.run(LookupDiscovery.java:1744)
>       at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331)
> Caused by: java.lang.SecurityException: attempt to add a Permission to
> a readonly Permissions object
>       at java.security.Permissions.add(Permissions.java:109)
>       at 
> sun.rmi.server.LoaderHandler.getLoaderAccessControlContext(LoaderHandler.java:981)
>       at sun.rmi.server.LoaderHandler.lookupLoader(LoaderHandler.java:857)
>       at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:381)
>       at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
>       at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
>       at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
>       at net.jini.loader.ClassLoading.loadClass(ClassLoading.java:138)
>       at 
> net.jini.io.MarshalInputStream.resolveClass(MarshalInputStream.java:296)
>       at 
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
>       at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
>       at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1508)
>       at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1463)
>       at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
>       at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
>       at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
>       at 
> java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:479)
>       at 
> com.sun.jini.reggie.RegistrarProxy.readObject(RegistrarProxy.java:269)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>       at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>       at java.lang.reflect.Method.invoke(Method.java:585)
>       at 
> java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
>       at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
>       at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
>       at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
>       at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
>       at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:358)
>       at 
> com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery(DiscoveryV1.java:397)
>       ... 8 more

Reply via email to