Die erholsame Annotation @RequestBody von SpringMVC konvertiert JSON- und Object_Javascript-Fähigkeiten

Aufgrund des bevorstehenden chinesischen Neujahrs hatte das Projektteam nicht viele Aufgaben, sodass ich im Frühling etwas freie Zeit hatte, um erholsame Anrufe zu studieren. Ich habe festgestellt, dass Spring so mächtig geworden ist, dass sich Programmierer beim Schreiben von Schnittstellen nicht mehr um die Datenkonvertierung und den Aufruf kümmern müssen, sondern sich nur noch auf das Geschäft konzentrieren müssen. Im Folgenden fasse ich die Schritte und Probleme zusammen, die während des Forschungsprozesses aufgetreten sind.

Schritte:

1. Git-Klon https://github.com/spring-guides/gs-rest-service.git Den Quellcode von der offiziellen Spring-Website heruntergeladen

2. Kompilieren Sie mit Maven (Gradle ist auch akzeptabel)

3. Führen Sie Folgendes aus und besuchen Sie http://localhost:8080/greeting

4. Das laufende Ergebnis kann das Objekt in ein JSON-Objekt konvertieren und an die Seite zurückgeben

Zu diesem Zeitpunkt habe ich darüber nachgedacht, wie ich die angeforderten Daten automatisch in ein Java-Objekt konvertieren kann. Über Google habe ich herausgefunden, dass Spring tatsächlich den HttpMessageConverter-Konverter bereitgestellt hat und MappingJackson2HttpMessageConverter (json ~object-Konvertierungsklasse) standardmäßig geladen wird . ). Konfigurieren Sie einfach @RequestBody Greeting Gree zur Verwendung.

Der Controller-Layer-Code lautet wie folgt:

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

Zu diesem Zeitpunkt habe ich über das Plug-in von Google (Postbote) einen Anruf getätigt, aber der Anruf über Leben und Tod war erfolglos!

Probleme analysieren und lösen:

Derzeit habe ich das Gefühl, dass die Ursache des Problems in den folgenden Aspekten liegen könnte:

1. Spring lädt MappingJackson2HttpMessageConverter standardmäßig nicht (ich kenne die spezifische Lademethode nicht)

2. MappingJackson2HttpMessageConverter funktioniert nach dem Laden nicht (ich kenne den Grund nicht, warum es nicht funktioniert)

Tatsächlich war der Grund, warum es am Ende nicht funktionierte, dass ich zu sehr an den Quellcode von Spring geglaubt habe (das Objekt stellte keine festgelegte Methode bereit). konnte die entsprechenden Ergebnisse nicht finden. Es bleibt nichts anderes übrig, als die Grundursache des Problems zu finden und sich den Spring-Quellcode anzusehen.

Zur ersten Frage:

Schritt 1: Den Ladetypkonverter manuell neu schreiben

@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 !!!!!");
  }
}

Der Test ergab, dass es immer noch nicht verwendet werden kann, und jetzt ist der Grund noch unklarer. Sie können standardmäßig nur sehen, wie die Feder den Typkonverter belastet. Es stellt sich heraus, dass in der Methode addDefaultHttpMessageConverters in WebMvcConfigurationSupport (das Schlüsselwort HttpMessageConverter wird reflektiert und dort gesucht, wo es verwendet wird, es durch Beurteilung und Verfolgung gefunden wird) wie folgt:

@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());
    }
  }

Der entsprechende Standardkonverter wurde geladen. Das Debuggen von Haltepunkten zeigt, dass mit der Standardkonfiguration kein Problem vorliegt.

Es kann nur gesagt werden, dass es durch das zweite Problem verursacht wird, aber ich weiß nicht, warum es dieses Problem verursacht hat (JSON-Datenproblem oder andere Probleme). Ohne das Problem zu kennen, kann ich mir nur die Anfrage ansehen Fordern Sie an und sehen Sie, wie der Konverter funktioniert. Da ich nicht viel über den Frühling weiß, kenne ich sein Prinzip nicht. In diesem Fall kann die entsprechende Verwendung nur anhand der Schlüsselklasse (HttpMessageConverter) gefunden werden. Nutzen Sie Ihre Erfahrung zum Beurteilen und Debuggen. Es wurde festgestellt, dass die readWithMessageConverters-Methode in AbstractMessageConverterMethodArgumentResolver die Verarbeitungsmethode für die Anforderung zur Typkonvertierung ist.

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);
  }

Zu diesem Zeitpunkt wurde festgestellt, dass der entsprechende Nachrichtenkonverter vom Typ MappingJackson2HttpMessageConverter gemäß der canRead-Methode von HttpMessageConverter gefunden wurde und die Konvertierung gestartet wurde, aber eine Laufzeitausnahme ausgelöst wurde. Denn die Ausnahme wird nicht auf der Konsole ausgegeben. Durch das Debuggen von Haltepunkten habe ich festgestellt, dass die readJavaType-Methode von MappingJackson2HttpMessageConverter eine Laufzeitausnahme ausgelöst hat. Durch den Quellcode habe ich festgestellt, dass die unterste Ebene von Jacksons objectMapper betrieben wird. Der Code lautet wie folgt:

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

Wenn ich den Code separat herausnehme und in der Hauptmethode ausführe, er aber immer noch nicht funktioniert, kann ich das Problem lokalisieren. Entweder ist der Typ falsch oder die Eingabedaten sind falsch. Nach sorgfältiger Prüfung habe ich festgestellt, dass es kein Problem mit den JSON-Daten gibt und diese auch mit JSONObject konvertiert werden können. Derzeit kann nur festgestellt werden, dass ein Problem mit dem eingehenden JavaType vorliegt. Wenn ich es öffne und feststelle, dass das Objekt (Begrüßung) keine festgelegte Methode hat, frage ich mich, ob das daran liegt, dass Jakson nicht funktionieren kann (das Prinzip ist nicht klar). Wenn ja, stelle ich die Set-Methode für dieses Objekt bereit und es kann erneut ausgeführt werden. Nachdem ich mich im Kreis bewegt hatte, löste ich schließlich das Problem, aber durch dieses Problem wurde mir der Arbeitsmechanismus der Federruhe bewusster.