Que se passe-t-il avec le résolveur d'arguments par défaut lorsque le résolveur personnalisé pour le même type est ajouté?

Question

Je veux limiter la valeur de la taille paginable maximale à 10 (valeur par exemple) et je peux le faire comme ça:

@Configuration 
public class MvcConfiguration extends WebMvcConfigurerAdapter { 

    @Override 
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> argumentResolvers) { 
     super.addArgumentResolvers(argumentResolvers); 
     PageableHandlerMethodArgumentResolver resolver = new PageableHandlerMethodArgumentResolver(); 
     resolver.setMaxPageSize(10); 
     argumentResolvers.add(resolver); 
    } 
} 

et delcare méthode du contrôleur comme celui-ci

@RequestMapping(name = "list") 
    public String listUsers(@PageableDefault(size = 5, page = 0) Pageable pageable) { 

En effet, cela fonctionnera , Je ne serai pas en mesure de définir la taille de la page à> 10, mais je suis curieux de savoir pourquoi? Qu'est-ce qui arrive au printemps créé PageableHandlerMethodArgumentResolver? Pourquoi cette instance est prise en compte et non celle par défaut? Après tout, je ne remplace pas les résolveurs ici, en ajoutant seulement un nouveau.

Answer 1

1. Phase de configuration

Lorsque vous étendez WebMvcConfigurerAdapter et ajoutez résolveurs personnalisés dans addArgumentResolvers, (sauter beaucoup de code de configuration) vous les ajoutez en fait RequestMappingHandlerAdapterRequestMappingHandlerAdapter haricot enregistre en interne la liste de tous les résolveurs, à condition lors de l'initialisation. (WebMvcConfigurationSupport). Après cela, ils sont combinés avec des résolveurs par défaut. Et comme vous pouvez le voir sur le source code, PageableHandlerMethodArgumentResolver ne fait pas partie de la liste des résolveurs par défaut, mais provient d'une classe de configuration. Et dans mon cas (capture d'écran ci-dessous) les classes de configuration fournissent spring-boot-starter-data-rest version différente de PageableHandler: HateoasPageableHandlerMethodArgumentResolver

2. résolveurs ordre

résolveurs personnalisés sont commandés Ones après intégrés (source). Donc, vérifions cela et appelons un contrôleur, mais mettez d'abord le point d'arrêt en RequestMappingHandlerAdapter.invokeHandlerMethod(). De là, nous pouvons voir l'état interne de RequestMappingHandlerAdapter

Je surligné résolveur personnalisé MyPageableHandlerMethodArgumentResolver, enregistré de la même manière que vous avez fait dans votre code question.

Et le code qui résout réellement les arguments est HandlerMethodArgumentResolverComposite. Il est simple boucle et cela signifie que le premier enregistré HandlerMethodArgumentResolver sera utilisé

for (HandlerMethodArgumentResolver methodArgumentResolver : this.argumentResolvers) 
    if (methodArgumentResolver.supportsParameter(parameter)) { 
     result = methodArgumentResolver; 
     this.argumentResolverCache.put(parameter, result); 
     break; 
    } 

Et comme vous pouvez le voir à partir du code source, le résultat est mis en cache et encore jamais réitérait pour le même type de paramètre.