Luke Taylor (Migrated from SEC-1196) said:
For better tooling support, it would make sense to follow the approach used in SEC-1186 for filters and apply the same logic to authentication providers. would register the ProviderManager and the contents would be parsed as a list of providers and references to provider beans.
etc. This would improve the context by keeping all providers together and ordered and would allow for proper tooling support. The bean decoration approach could still be partially supported by generating a list of providers from the decorated beans. A post-processor would check the context for the presence of the standard AuthenticationManager and if one wasn't found, it would be created from the provider list. Otherwise an error would be reported and a message produced suggesting that provider elements be placed within the element. The internal AuthenticationManagers produced in SEC-1195 would delegate to the one created by this element (using the standard bean name). It could thus be placed anywhere in the application context
Luke Taylor said:
The suggested changes have been made, with the exception that the original approach (using the decorator element, ) is no longer supported. It is now required that the user include the element somewhere in their configuration (thus fixing the location of the AuthenticationManager bean, in terms of which application context it appears in). The (or ) elements must be children of the .
This issue depends on #1443