Luke Taylor (Migrated from SEC-1186) said:
The decorator approach complicates things when it comes to parsing the filter list and makes it difficult to provide proper tooling integration (since we have to rely on a bean processor to build the final filter list). This approach makes sense with the AuthenticationManager since the implementation is not visible, but it would make things clearer if the block contained a complete definition of the filter list, rather than having to scan through the rest of the configuration for filter beans with in them.
So we would have
The existing bean parser can be modified to provide a suitable message and example of the new syntax.
Luke Taylor said:
I've added the code to make this possible and remove the decorator-based approach. This has also led to other major changes in parsing the element. The filter chain is now created entirely during parsing as a list of bean definitions and this should improve the representation in Spring IDE. Many of the global bean identifiers for filters have been removed completely, sine there is no longer any need to access them elsewhere. If necessary, the beans are registered using a generated name.