L'annotation reposante SpringMVC @RequestBody convertit les compétences json et object_javascript

En raison du Nouvel An chinois à venir, l'équipe du projet n'avait pas beaucoup de tâches, j'ai donc eu du temps libre pour étudier les appels réparateurs au printemps. J'ai découvert que Spring est devenu si puissant que les programmeurs n'ont plus besoin de se soucier de la conversion des données et de l'invocation dans le processus d'écriture des interfaces, mais doivent uniquement se concentrer sur les affaires. Ci-dessous, je résume les étapes et les problèmes rencontrés au cours du processus de recherche.

Étapes :

1. git clone https://github.com/spring-guides/gs-rest-service.git Téléchargé le code source depuis le site officiel du printemps

2. Compiler avec maven (gradle est également acceptable)

3. Exécutez et visitez http://localhost:8080/greeting

4. Le résultat en cours d'exécution peut convertir l'objet en objet json et le renvoyer à la page

À ce moment-là, je réfléchissais à la façon de convertir automatiquement les données demandées en un objet Java. Grâce à Google, j'ai découvert que Spring avait en fait fourni le convertisseur HttpMessageConverter et que MappingJackson2HttpMessageConverter (json ~ classe de conversion d'objet) était chargé par défaut. . Configurez simplement @RequestBody Greeting pour l'utiliser.

Le code de la couche contrôleur est le suivant :

@RequestMapping(value = "/greeting", method = RequestMethod.POST,consumes = "application/json")
  public @ResponseBody Greeting greeting(@RequestBody Greeting gree) {
    System.out.println(gree.getContent());
    return gree;
  }

À ce moment-là, j'ai passé un appel via le plug-in de Google (postman), mais l'appel de vie ou de mort n'a pas abouti !

Analyser et résoudre des problèmes :

À l'heure actuelle, je pense que la cause du problème peut résider dans les aspects suivants :

1. Spring ne charge pas MappingJackson2HttpMessageConverter par défaut (je ne connais pas la méthode de chargement spécifique)

2. MappingJackson2HttpMessageConverter ne peut pas fonctionner après le chargement (je ne connais pas la raison pour laquelle cela ne fonctionne pas)

En fait, la raison pour laquelle cela n'a finalement pas fonctionné était que je croyais trop au code source de spring (l'objet ne fournissait pas de méthode définie. Avec ces deux questions, les chercheurs massifs sur Internet). n'a pas pu trouver les résultats correspondants. Il n'y a pas d'autre moyen que de trouver la cause première du problème et de consulter le code source du printemps.

Pour la première question :

Étape 1 : Réécrire manuellement le convertisseur de type de chargement

@Configuration
  @EnableWebMvc
public class WebConfiguration extends WebMvcConfigurerAdapter {
  public void configureMessageConverters(List<HttpMessageConverter<&#63;>> messageConverters) {
    System.out.println("init convert is start !!!!!");
    StringHttpMessageConverter stringConverter = new StringHttpMessageConverter();
    stringConverter.setWriteAcceptCharset(false);
    messageConverters.add(new MappingJackson2HttpMessageConverter());
    System.out.println("init convert is stop !!!!!");
  }
}

Le test a révélé qu'il ne peut toujours pas être utilisé, et maintenant la raison est encore moins claire. Vous ne pouvez voir que comment le ressort charge le convertisseur de type par défaut. Il s'avère que dans la méthode addDefaultHttpMessageConverters dans WebMvcConfigurationSupport (le mot-clé HttpMessageConverter est reflété et recherché là où il est utilisé, il est trouvé par jugement et suivi) comme suit :

@SuppressWarnings("deprecation")
  protected final void addDefaultHttpMessageConverters(List<HttpMessageConverter<&#63;>> messageConverters) {
    StringHttpMessageConverter stringConverter = new StringHttpMessageConverter();
    stringConverter.setWriteAcceptCharset(false);
    messageConverters.add(new ByteArrayHttpMessageConverter());
    messageConverters.add(stringConverter);
    messageConverters.add(new ResourceHttpMessageConverter());
    messageConverters.add(new SourceHttpMessageConverter<Source>());
    messageConverters.add(new AllEncompassingFormHttpMessageConverter());
    if (romePresent) {
      messageConverters.add(new AtomFeedHttpMessageConverter());
      messageConverters.add(new RssChannelHttpMessageConverter());
    }
    if (jaxb2Present) {
      messageConverters.add(new Jaxb2RootElementHttpMessageConverter());
    }
    if (jackson2Present) {
      messageConverters.add(new MappingJackson2HttpMessageConverter());
    }
    else if (jacksonPresent) {
      messageConverters.add(new org.springframework.http.converter.json.MappingJacksonHttpMessageConverter());
    }
  }

Le convertisseur par défaut correspondant a été chargé. Le débogage des points d'arrêt montre qu'il n'y a aucun problème avec la configuration par défaut.

On peut seulement dire que cela est causé par le deuxième problème, mais je ne sais pas pourquoi cela a causé ce problème (problème de données json, ou autres problèmes). Sans connaître le problème, je ne peux que regarder la demande. demander et voir comment fonctionne le convertisseur. Parce que je ne connais pas grand chose au printemps, je ne connais pas son principe. Dans ce cas, l'utilisation correspondante ne peut être trouvée que sur la base de la classe de clé (HttpMessageConverter). Utilisez l'expérience pour juger et déboguer. Il s'avère que la méthode readWithMessageConverters dans AbstractMessageConverterMethodArgumentResolver est la méthode de traitement de la requête pour effectuer une conversion de type.

protected <T> Object readWithMessageConverters(HttpInputMessage inputMessage,
      MethodParameter methodParam, Type targetType) throws IOException, HttpMediaTypeNotSupportedException {
    MediaType contentType;
    try {
      contentType = inputMessage.getHeaders().getContentType();
    }
    catch (InvalidMediaTypeException ex) {
      throw new HttpMediaTypeNotSupportedException(ex.getMessage());
    }
    if (contentType == null) {
      contentType = MediaType.APPLICATION_OCTET_STREAM;
    }
    Class<&#63;> contextClass = methodParam.getContainingClass();
    Class<T> targetClass = (Class<T>) ResolvableType.forType(targetType,
        ResolvableType.forMethodParameter(methodParam)).resolve();
    for (HttpMessageConverter<&#63;> converter : this.messageConverters) {
      if (converter instanceof GenericHttpMessageConverter) {
        GenericHttpMessageConverter<&#63;> genericConverter = (GenericHttpMessageConverter<&#63;>) converter;
        if (genericConverter.canRead(targetType, contextClass, contentType)) {
          if (logger.isDebugEnabled()) {
            logger.debug("Reading [" + targetType + "] as \"" +
                contentType + "\" using [" + converter + "]");
          }
          return genericConverter.read(targetType, contextClass, inputMessage);
        }
      }
      if (targetClass != null) {
        if (converter.canRead(targetClass, contentType)) {
          if (logger.isDebugEnabled()) {
            logger.debug("Reading [" + targetClass.getName() + "] as \"" +
                contentType + "\" using [" + converter + "]");
          }
          return ((HttpMessageConverter<T>) converter).read(targetClass, inputMessage);
        }
      }
    }
    throw new HttpMediaTypeNotSupportedException(contentType, allSupportedMediaTypes);
  }

À ce moment-là, il a été découvert que le convertisseur de message de type correspondant MappingJackson2HttpMessageConverter avait été trouvé selon la méthode canRead de HttpMessageConverter, et que la conversion avait commencé, mais une exception d'exécution a été levée. Parce que l'exception n'est pas affichée sur la console. Grâce au débogage du point d'arrêt, j'ai découvert que la méthode readJavaType de MappingJackson2HttpMessageConverter a généré une exception d'exécution. Grâce au code source, j'ai découvert que la couche inférieure est exploitée par l'objectMapper de Jackson. Le code est le suivant :

.

try {
      return this.objectMapper.readValue(inputMessage.getBody(), javaType);
    }
    catch (IOException ex) {
      throw new HttpMessageNotReadableException("Could not read JSON: " + ex.getMessage(), ex);
    }

Si je retire le code séparément et que je l'exécute dans la méthode principale, mais que cela ne fonctionne toujours pas, je peux alors localiser le problème. Soit le type est erroné, soit les données d'entrée sont erronées. Après une inspection minutieuse, j'ai constaté qu'il n'y avait aucun problème avec les données json et qu'elles pouvaient également être converties à l'aide de jsonobject. Pour le moment, on peut seulement juger qu'il y a un problème avec le javaType entrant. Si je l'ouvre et constate que l'objet (Greeting) n'a pas de méthode définie, je me demande si c'est parce que Jackson ne peut pas fonctionner (le principe n'est pas clair). Si tel est le cas, je fournis la méthode set pour cet objet et il peut être réexécuté. Après avoir tourné en rond, j'ai finalement résolu le problème, mais grâce à ce problème, je suis devenu plus conscient du mécanisme de fonctionnement du repos du ressort.