refactor: allow multiple UaaTokenEnhancers

[peterhaochen47]

• previously, only one is allowed
• add setUaaTokenEnhancers function to allow adding multiple UaaTokenEnhancers
• for now, keep setUaaTokenEnhancer function intact (it just adds a UaaTokenEnhancer now) for backward compatibility; even though the naming of this function is a little misleading now, it functions the same as before.
  • If backward compatibility is not a concern (aka there is no external code relying on setUaaTokenEnhancer, neither explicitly nor implicitly via spring), we could remove this function (and migrate to setUaaTokenEnhancers).

[fhanik]

API change here. Would it be better to add addUaaTokenEnhancer in addition to the set, which overwrites everything? and perhaps deprecate the setUaaTokenEnhancer

setUaaTokenEnhancer went from idempotent to non idempotent, and that is because it is a List, not a Set.

[fhanik]

@peterhaochen47 You could already achieve a list of token enhancers today by setting an object that implements TokenEnhancer, and that object has a list of token enhancers in it.

This PR can still be accepted, but I'm thinking that setUaaTokenEnhancer should not be allowed to add the same object many times. Instead make the list a set, and add addUaaTokenEnhancer.

set should act as before, overrides the previous one, and set can be marked deprecated, or should have separate javadoc

add - when working on a set, should remove the object first, and then add it back to the end.

[duanemay]

Order these are applied may become important, so a list seems more appropriate.

[strehle]

@gdgenchev FYI you should be aware of such change and @adrianhoelzl-sap

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[peterhaochen47]

created alternative PR based on feedback: #3904

[gdgenchev]

Another similar approach would be to rely on the spring wiring for the list of beans by injecting the list directly in the constructor. If multiple enhancers are needed, you just define multiple beans that automatically get injected to the list. If order is important, you use @Order annotation over each bean. If no beans are found, spring will inject empty list.

This approach could be used if we align that we would expect UaaTokenEnhancer beans and no manual calling of the setter i.e. deprecate the setter and later delete it.

Note that I recently added the @Autowired over the setter to make it easier to inject a token enhancer to the UaaTokenServices, as it was tedious without it (had to use BeanPostProcessor for UaaTokenServices to call the setter).

[peterhaochen47]

Another similar approach would be to rely on the spring wiring for the list of beans by injecting the list directly in the constructor. If multiple enhancers are needed, you just define multiple beans that automatically get injected to the list. If order is important, you use @Order annotation over each bean. If no beans are found, spring will inject empty list.

This approach could be used if we align that we would expect UaaTokenEnhancer beans and no manual calling of the setter i.e. deprecate the setter and later delete it.

Note that I recently added the @Autowired over the setter to make it easier to inject a token enhancer to the UaaTokenServices, as it was tedious without it (had to use BeanPostProcessor for UaaTokenServices to call the setter).

Yes, that's how I plan to use it, to supply multiple beans, rather than calling setter explicitly (I have tested that it works). I'm keeping the old setter for backward compatibility. See new PR: #3904

[peterhaochen47]

closing in favor of #3904