To patch or not to patch?

[Peter <ji...@zeus.net.au>]

I'm a little hesitant, given recent events, however I think I should ask 
the question.

This patch is applied to my local copy of River, either I can revert my 
local copy in preparation for building River 3.0 release artifacts, or I 
should commit it?

What does this patch address?

PermissionComparator is used in a number of places, in 
CombinerSecurityManager and policy provider implementations.  It avoids 
equals and hashcode methods and orders Permissions in Sets and avoids 
duplicates to improve performance during permission checks.  It helps to 
avoid a number of DNS calls that SocketPermission might cause.

PrivateCredentialPermission, is a relatively complex permission.

Most permission implementations have a two argument constructor; name 
and argument strings.  PrivateCredentialPermission has this constructor, 
when used, the name argument passed to the constructor is returned by 
the getName() method.

However during permission checks, the getName() method only returns the 
credential class.  Crucial information is missing, namely principal 
classes and principals, it results in incorrect results for 
PrivateCredentialPermission when using PermissionComparator.  When using 
PermissionComparator in a Set, a number of PrivateCredentialPermissions 
may be missing, as they are deemed equal by the PermissionComparator 
when they are not.  The only way to address this issue, is to access the 
information contained in PrivateCredentialPermission using other methods.

Hence the patch attached.

I discovered this discrepancy while dynamically generating policy files 
and testing those files for use a policy files.

Shall I submit this to trunk now, before generating  River 3.0 release 
artifacts this coming weekend?  Or should I report the issue to JIRA 
after release?

Regards,

Peter.