Johannes Scharf (Migrated from SEC-1290) said:
The javadoc of OrderedFilterBeanDefinitionDecorator says:
If the user's filter already implements Ordered, and no "order" attribute is specified, the filter's default order will be used.
When a custom filter is specified via a "custom-filter" element without an "after", "before" or "position" attribute in the configuration, altough it implements the "Ordered" interface, the OrderedFilterBeanDefinitionDecorator always throws the exception:
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: A single 'after', 'before', or 'position' attribute must be supplied
This behaviour obvisiously violates the contract defined by the javadoc and the documentation of the "custom-filter" element.
I think the problem is at line 63 of the OrderedFilterBeanDefinitionDecorator class. It would be sufficient to remove that code as the "order" attributes are checked again at line 110 with respect if the filter implements at least the "Ordered" interface.
Johannes Scharf said:
This affects at least version 2.0.5 of Spring Security.
Luke Taylor said:
This is essentially an out-of-date doc issue. The intention is now that you should specify the position of the filter relative to the filter stack, rather than by using explicit order values. The latter approach is fragile, as filters may be added or removed to the stack with new versions of the framework and users need to know the order numbers assigned to the internal filters. There is no benefit over using a relative positioning approach.
In 3.0, the filter chain order is determined before the beans in the application context are actually instantiated, so by the time the order obtained from the filter instance was obtainable, it would be too late.
Closing as "won't fix? since this doesn't apply to 3.0