Fix customizer ordering

[king-407]

Summary

Fixes #3320.

This updates Springdoc customizer execution so customizers are applied according to Spring ordering semantics such as @Order.

Previously, several customizer collections were stored as Sets and iterated directly, so the execution order could depend on set iteration order instead of Spring's ordering rules.

Changes

• Apply OpenApiCustomizer instances in Spring order.
• Apply OperationCustomizer instances in Spring order.
• Apply RouterOperationCustomizer instances in Spring order.
• Apply DataRestRouterOperationCustomizer instances in Spring order.
• Apply OpenApiLocaleCustomizer beans using Spring's ordered bean stream.
• Add a focused regression test for ordered customizer execution.

Testing

mvn -q -pl springdoc-openapi-starter-common -Dtest=SpringDocCustomizersTest test
git diff --check

[zhujianxintian]

@king-407 Thank you for your help! Much appreciated 🙏

However, there is one thing I don't quite understand: why was the existing custom item collection API retained? I noticed that most of the places where it was used have also been modified, and it seems that using ObjectProvider wouldn't make much of a difference.

(I prefer using ObjectProvider because when reading the source code, if the type is ObjectProvider, it indicates that @Order is likely supported—this is more intuitive than List or Set. With List or Set, you only know @Order works if you check the call site, or if you don't read the source code and just use @Order directly.)

I'm curious—is this due to compatibility concerns, or is there another reason?

[king-407]

@zhujianxintian Thanks for taking a look.

Yes, the main reason was to keep the change narrow and avoid changing the existing SpringDocCustomizers construction API in this PR.

SpringDocCustomizers is also created from GroupedOpenApi customizer collections, not only from Spring bean injection, so I kept the existing collection-based API and centralized the ordering at the point where the customizers are consumed.

That said, I agree that ObjectProvider communicates Spring ordering support more clearly when reading the code. If the maintainers prefer that direction, I’m happy to refactor the bean-injected customizers to use ObjectProvider while keeping the grouped/custom collection path working as well.

[zhujianxintian]

Thank you for your reply, I understand the reason for doing this now.

Both ObjectProvider and your approach can satisfy Spring's ordering support; the former is more concise but more aggressive, while the latter is more stable and compatible.

I raised this question only because I wanted to improve readability further, but perhaps the latter is indeed more prudent at the moment. Both ways are good.

Thank you for your contribution.