Auto-configure HandlerMethodArgumentResolvers on AnnotatedControllerConfigurer

[maxhov]

Add an AnnotatedControllerConfigurerCustomizer to provide a friendly API to modify the autoconfiguredAnnotatedControllerConfigurer. End users could provide HandlerMethodArgumentResolvers without having to override the entire AnnotatedControllerConfigurer bean.

This has been discussed in (amongst others) spring-projects/spring-graphql#603, but there seems no way to customize the AnnotatedControllerConfigurer. This PR aims to improve the API for end users.

[maxhov]

I see that the build fails on a missing @since in the Javadoc. Which version should I use here? Is it probable that it will make it into 3.3.0 still?

[philwebb]

@maxhov I'm afraid we'll probably not get this into 3.3 since we just cut RC1, but feel free to use that as the @Since tag. We can fix it up later.

[bclozel]

Why not auto-configure HandlerMethodArgumentResolver beans on that component in the existing configuration? To me customizers are useful when lots of options exist and when applications want to contribute several.

[maxhov]

@bclozel I chose this approach because it is also used for GraphQlSourceBuilder via GraphQlSourceBuilderCustomizer and it seemed sensible to take the same approach.

[bclozel]

The org.springframework.graphql.execution.GraphQlSource.Builder not only configures many things, but also is the gateway to configuring the GraphQL engine itself. The AnnotatedControllerConfigurer has less options and in this case, the HandlerMethodArgumentResolver are ordered, which means AnnotatedControllerConfigurerCustomizer should be ordered themselves or a single AnnotatedControllerConfigurerCustomizer should add all argument resolvers.

I think that as a first step, we should consider HandlerMethodArgumentResolver beans and set them on the configurer in an ordered fashion. I think we're too late in the cycle to consider this feature now.

[maxhov]

@bclozel I am not sure I understand. Registering either HandlerMethodArgumentResolver or AnnotatedControllerConfigurerCustomizer beans both need to be explicitely ordered via @Order/Ordered at the bean declaration, so which bean is defined would not really matter for that purpose?

Maybe exposing more methods on the AnnotatedControllerConfigurer API is not desirable at this moment, I can change the implementation to accepting HandlerMethodArgumentResolver beans and registering them. Let me know if you are open to that, then I will change the implementation as such. I understand that for 3.3 this may be too late.