org.springframework.core.annotation.AnnotationAwareOrderComparator
extends org.springframework.core.OrderComparator
and ultimately ends up calling this method:
protected int getOrder(@Nullable Object obj) {
if (obj != null) {
Integer order = findOrder(obj);
if (order != null) {
return order;
}
}
return Ordered.LOWEST_PRECEDENCE;
}
Very similar to the problem in #24058 , this defaulting is causing some third-party RestTemplateCustomizer
instances, that don't specify any sorting, to be added at the end of the list, making it impossible for me to add a RestTemplateCustomizer that operates after the third-party one.
I'm not sure about the implications of such a change, but is there any reason why the fallback value isn't 0
or even Ordered.LOWEST_PRECEDENCE-1
?
Ideally, and without knowing the implications, 0 is what makes the most sense to me, but anything that isn't LOWEST_PRECEDENCE
would at least offer a way of adding things after.
Comment From: rubasace
Any feedback on this issue?
Comment From: snicoll
We can't unfortunately go with a default of 0 as it would give a precedence of a bean that doesn't define one.
this defaulting is causing some third-party RestTemplateCustomizer instances, that don't specify any sorting, to be added at the end of the list, making it impossible for me to add a RestTemplateCustomizer that operates after the third-party one.
I would argue that the third party not having an explicit default to be also part of the problem here. With its ordering undefined, it's not unreasonable that it runs after the ones that do have one.