2017-09-27 5 views
0

ajouter Converter s via FormattingConversionService, ce qui nécessite d'avoir une classe de @Configuration extension WebMvcConfigurationSupport:Comment utiliser WebMvcConfigurationSupport de propre, je voudrais auto-configuration

@Configuration 
public class WebAutoConfig extends WebMvcConfigurationSupport { 

    @Override 
    public FormattingConversionService mvcConversionService() { 

     FormattingConversionService fcs = super.mvcConversionService(); 

     // add Enum converter in order to accept enums 
     // case insensitively over Rest: 
     fcs.addConverter(
       String.class, 
       MyEnum.class, 
       new EnumCaseInsensitiveConverter<>(MyEnum.class) 
     ); 

     return fcs; 
    } 
} 

Il fonctionne très bien lorsque le @Configuration est utilisé directement à partir du projet, mais il est nécessaire d'ajouter cette logique à notre propre boot-starter afin qu'il ne soit pas nécessaire de dupliquer le code dans tous les projets.

Le problème est, lorsque ce @Configuration est migré vers un projet de démarrage, puis

  • mvcConversionService() n'est pas exécuté, et
  • routage des RestControllers est cassé (pas de demandes sont mises en correspondance correctement).

Comment aborder cela? Remarque en utilisant WebMvcConfigurationSupport n'est pas une exigence difficile. Comme le montre l'extrait de code, l'objectif final est de configurer certaines énumérations pour qu'elles soient acceptées par les contrôleurs restants sans tenir compte de la casse.

Modifier: il convient d'ajouter que le projet auto-config est correctement configuré, comme d'autres @Configuration classes dans le même paquet que WebAutoConfig.java exécutent. Pensez que le problème a à voir avec la façon dont les classes de configuration qui s'étendent WebMvcConfigurationSupport (ou WebMvcConfigurerAdapter d'ailleurs) sont gérées à partir des auto-configs.

Edit2: seule façon que j'ai réussi à se rendre au travail à ce jour est l'extension de la classe de configuration du projet en utilisant:

import myautoconfproject.autoconfigure.WebAutoConfiguration; 

@Configuration 
public class WebConfiguration extends WebAutoConfiguration { 
} 

Mais ce n'est pas vraiment auto-configuration plus.

+0

Quelle est la configuration de votre démarreur Il n'y a pas de véritable magie noire pour mettre en œuvre votre propre entrée, autre que Condit chargement ionique de celui-ci. Êtes-vous certain que la configuration serait scannée par votre démarreur? –

+0

@DarrenForsythe Oui, il est certainement repris car autoconfig entrypoint comprend '@ ComponentScan'. Il existe également d'autres classes '@ Configuration' dans le même paquet qui sont en cours d'exécution. – laur

Répondre

0

Apparemment, je me suis trompé sur le WebMvcConfigurerAdapter - que l'on est pris par auto-config:

@Configuration 
public class WebAutoConfig extends WebMvcConfigurerAdapter { 

    @Override 
    public void addFormatters(final FormatterRegistry registry) { 

     registry.addConverter(
       String.class, 
       MyEnum.class, 
       new EnumCaseInsensitiveConverter<>(MyEnum.class) 
     ); 
    } 
} 
0

Pour que votre configuration pour obtenir ramassé automatiquement pour des projets qui incluent votre projet en tant que dépendance, vous devez ajouter le fichier META-INF/spring.factories à votre classpath (dans le projet où WebAutoConfig mensonges et ajoutez les lignes

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ 
your.package.WebAutoConfig 
+0

Ce n'est pas le problème. L'entrée entrante 'EnableAutoConfiguration' est déjà définie dans' spring.factories', pointant vers une autre classe dans le projet autoconfig, qui inclut '@ ComponentScan' pointant vers d'autres classes' @ Configuration', y compris 'WebAutoConfig'. Voir mon commentaire sous la question. Le problème, autant que je peux dire, semble être comment 'WebMvcConfigurerAdapter' est/peut être utilisé à partir de autoconfig. – laur