Seems like the only way to deal with the problem is via work arounds. Using a Comparator<SocketPermission> is one option, to arrange the permissions so:
1. Identical check using comparator. 2. wild cards are checked. 3. IP addresses. 4. Last check domain name addresses. Alternatively, we can use a replacement inside the policy only, or ConcurrentPermissions, as an internal implementation detail. ConcurrentPermissions can be used inside ProtectionDomain too, important, since PD's internal Permissions are checked after the policy, if it doesn't imply. Also static ProtectionDomains never consult the policy, their classloader might during their construction, but that's it. The policy also merges the ProtectionDomain's internal Permissions, with the policy. In addition, use dnsjava as the name service provider, and make dns lookup and reverse lookup property options. Cheers, Peter. ----- Original message ----- > On 1/3/2012 3:18 AM, Simon IJskes - QCG wrote: > > On 31-12-11 14:33, Peter wrote: > > > Any thoughts or experience replacing java classes using the > > > -Xbootclasspath option? > > > This means creating a new java.net.SocketPermission, completely > > > replacing it and SocketPermissionCollection in the jvm libraries. > > > > My gut feeling tells me, do not go there. Is this because of the lookup > > problem? We can assume river is only used on LAN's and when we use it on > > the internet, do we still need the socketpermission as a safety measure? > > In addition to any technical issues, we would need permission from > Oracle. The -Xbootclasspath documentation points out that "Applications > that use this option for the purpose of overriding a class in rt.jar > should not be deployed as doing so would contravene the Java 2 Runtime > Environment binary code license.". > > My own gut feeling is that we would be very unlikely to get that > permission, especially when the override might weaken security. > > Patricia
