2017-12-22 4 views
0

Ich habe einen Fehler, wenn ich versuche, dieses Attribut zu deserialisieren:Deserialize Local mit Jackson

@JsonDeserialize(using = LocalDateTimeDeserializer.class) 
@JsonSerialize(using = LocalDateTimeSerializer.class) 
private LocalDateTime deliveryDate; 

Dies ist die Deserialisierung Klasse:

public class LocalDateTimeDeserializer extends JsonDeserializer<LocalDateTime> { 

    @Override 
    public LocalDateTime deserialize(JsonParser parser, DeserializationContext context) throws IOException { 

     if (parser.getCurrentToken().equals(JsonToken.VALUE_STRING)) { 
      String rawDate = parser.getText(); 
      return LocalDateTime.parse(rawDate); 
     } else { 
      throw context.wrongTokenException(parser, JsonToken.VALUE_STRING, "Expected string."); 
    } 
} 

Und die Serialisierung Klasse:

public class LocalDateTimeSerializer extends JsonSerializer<LocalDateTime> { 

    @Override 
    public void serialize(LocalDateTime value, JsonGenerator gen, SerializerProvider serializers) throws IOException { 

     gen.writeString(value.toString()); 
    } 

Das ist der Fehler, den ich bekomme:

"timestamp":1513962011642,"status":400,"error":"Bad Request","exception":"org.springframework.http.converter.HttpMessageNotReadableException","message":"Could not read document: Text '2017-12-22T16:00:00.874Z' could not be parsed, unparsed text found at index 23 

Wissen Sie warum?

Danke!

+0

Mögliches Duplikat von [Java 8 LocalDate Jackson-Format] (https://StackOverflow.com/questions/28802544/java-8-localdate-Jackson-format) – sebadagostino

+0

Was sind die eigentlichen Originaldaten im JSON?1513962011642? –

+0

Die ursprünglichen Daten sind 2017-12-22T16: 00: 00.874Z – Anna

Antwort

1

tl; dr

Prozess als Instant anstatt LocalDateTime.

Instant.parse("2017-12-22T16:00:00.874Z") 

Einzelheiten

Nicht sicher Ihrer Originaldaten von JSON. Wenn Ihre Eingabedaten 1513962011642 sind, scheint es eine Zählung seit einer Epoche zu sein, vermutlich eine epoch reference date von 1970-01-01T00: 00: 00Z, der erste Moment von 1970 in UTC.

Instant instant = Instant.ofEpochMilli(1_513_962_011_642L) ; 

Wenn der ursprüngliche Eingang 2017-12-22T16:00:00.874Z ist, parst direkt als Instant. Diese Zeichenfolge befindet sich im Standardformat ISO 8601. Die Z am Ende ist die Abkürzung für Zulu und bedeutet UTC.

Die Klassen java.time verwenden standardmäßig die Standardformate beim Parsen/Erzeugen von Strings.

Instant instant = Instant.parse("2017-12-22T16:00:00.874Z") ; 

Ein LocalDateTime fehlt absichtlich jedes Konzept eines time zone oder offset from UTC, so tut es nicht ein tatsächliches Moment dar und ist kein Punkt auf der Timeline. Sie versuchen fälschlicherweise, Ihren Wert in die falsche Klasse zu passen, wobei die Tatsache, dass es sich um einen UTC-Wert handelt, nicht dargestellt werden kann.

Stattdessen verarbeiten Sie diesen Eingang als Instant Objekt. Ein Instant repräsentiert einen Punkt auf der Timeline in UTC mit einer Auflösung von nanoseconds.

+1

'timestamp'' 1513962011642' ist die Zeit der HTTP-Anfrage, die nicht mit der Textdatumsfolge zusammenhängt, die den Fehler erzeugt. –

+0

Danke für die Erklärung :) – Anna

0

Eigentlich ist der Fehler ziemlich einfach, es sagt, dass der Frühling diese Zeichenfolge "2017-12-22T16:00:00.874Z" zu LocalDateTime deserialize nicht kann. Wenn Sie den nächsten Code ausführen werden Sie den gleichen Fehler sehen:

public static void main(String[] args) { 
    System.out.println(LocalDateTime.parse("2017-12-22T16:00:00.874Z")); 
} 

Die Quelle des Fehlers ist Charakter 'Z' bei Index 23. Wenn Sie dieses Zeichen entfernen wird über der Code funktioniert. Daher würde ich Ihnen empfehlen zu überprüfen, warum dieses 'Z' Zeichen in der Zeichenfolge vorhanden ist, während Ihr Serializer es nicht hinzufügt.

+1

Schlechter Rat. Das Verwerfen des "Z" wirft Informationen weg, die Tatsache, dass diese Zeichenfolge einen Moment in UTC darstellt. Das eigentliche Problem ist, dass die Eingabe als "Instant" und nicht als "LocalDateTime" verarbeitet werden sollte. –

+0

Während ich zugeben, dass Z vorhanden sein kann es die Zeichenfolge, die ich nicht vorgeschlagen habe, es zu entfernen. Und die Frage ist nicht über die Notwendigkeit der Anwesenheit dieses Charakters. Die Frage ist - warum der Fehler auftritt, ist die Antwort - Deserializer kann solche Zeichenfolge wegen der Anwesenheit von Z-Zeichen nicht deserialisieren, die während der Serialisierung nicht hinzugefügt wird. Und Rat ist, herauszufinden, warum es da ist. Unterschiedliches Format auf Server und Client könnte der Grund sein, aber ich kann nicht so kategorial wie Sie sein, weil ich nicht genug Details habe. –

+0

Danke für die Erklärung :) – Anna

Verwandte Themen