Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Portlet mapping predicate compareTo is not transitive [SPR-9874] #14507

Closed
spring-projects-issues opened this issue Oct 11, 2012 · 1 comment
Closed
Assignees
Labels
type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Oct 11, 2012

Eric Dalquist opened SPR-9874 and commented

While the obvious part of the problem where the wrong handler is found has been fixed by #13941 and #14239 the compareTo implementation of the ActionMappingPredicate, EventMappingPredicate, RenderMappingPredicate, and ResourceMappingPredicate is still incorrect.

The compareTo javadoc states
The implementor must also ensure that the relation is transitive: (x.compareTo(y)>0 && y.compareTo(z)>0) implies x.compareTo(z)>0

The problem here is any two predicates of different types that both implement SpecialRequestTypePredicate are treated as equal.

For example with three predicates defined as:
A = RenderMappingPredicate(windowState=null, params=[])
B = ResourceMappingPredicate(resourceId="b");
C = RenderMappingPredicate(windowState=null, params=["c=c"])

If they are placed in an array as [A, B, C] then comparing them A.compareTo(B) == 0 and B.compareTo(C) == 0 happens when sorting and the list is "sorted" and implies that A.compareTo(C) == 0 even though A.compareTo(C) == -1

I believe the solution is that when comparing SpecialRequestTypePredicates that are different concrete classes the returned value should be the result of "this.getClass().getName().compareTo(other.getClass().getName())". This will result in predicates of the same types being grouped together and then being sorted by the type specific comparison logic. It should also completely fulfill the compareTo contract.

While there isn't currently a demonstrable bug with the code due to the change in the mapping resolution logic made for #13941 fixing compareTo will result help protect against potential future bugs where someone assumes a correctly implemented compareTo method.


Affects: 3.1.3, 3.2 RC1

Referenced from: commits 8f8e517, a6bcda2

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 11, 2012

Eric Dalquist commented

Submitted pull request: #164

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug
Projects
None yet
Development

No branches or pull requests

2 participants