Nous avons une application Java EE 7 exécutée sur un WildFly 9, consistant en un déploiement EAR éclaté, qui contient plusieurs fichiers WAR, des JAR au niveau EAR et un dossier lib contenant des JAR tiers. (Je sais que ce n'est pas comme ça qu'on ferait aujourd'hui, mais c'est comme ça.) L'un des WAR contient un service JAX-RS REST, qui GET et POST un objet de données qui contient un Java 8 OffsetDateTime. Comme JSON-B n'est pas encore disponible, nous avons utilisé @JsonSerialize/@JsonDeserialize sous la forme jackson-databind afin de le rassembler depuis et vers JSON.

Cela fonctionnait assez bien jusqu'à ce qu'en raison d'un changement d'un autre WAR, la dépendance jackson-jaxrs soit entrée dans le dossier lib au niveau EAR. Ce qui s'est passé ensuite, c'est que le marshalling a cessé de fonctionner, car le conteneur a essayé de définir la chaîne de date de JSON directement dans le type OffsetDateTime et, lors de l'obtention, d'écrire tous les champs internes de la date Java 8 au lieu de la chaîne formatée . J'ai supposé que le traitement des annotations mentionnées ci-dessus n'avait pas eu lieu et le serveur a donc essayé de les mapper comme d'autres types simples. Lorsque j'ai supprimé les JAR appartenant à la dépendance jackson-jaxrs, tout fonctionnait à nouveau correctement. Le serveur d'applications a alors probablement utilisé sa propre version de ce même JAR à partir de son dossier modules.

Ma question est donc la suivante : quelle est la différence lorsque vous avez le JAR jackson-jaxrs dans le dossier lib EAR en plus du module fourni par le système ou uniquement de ce dernier ? Pourquoi ne prend-il pas en compte les annontaions dans le premier cas lors de la dé/sérialisation ?

2
Alexander Rühl 30 janv. 2020 à 18:48

1 réponse

Meilleure réponse

Wildfly 9 regroupe jackson 1.9 en tant que module de base et les annotations se trouvent dans le package org.codehaus.jackson. Je soupçonne que la bibliothèque ajoutée récemment est la (plus récente) jackson 2.x et que les annotations se trouvent maintenant dans le package com.fasterxml.jackson.

Si tel est le cas, la mise à niveau vers jackson 2.x (idéalement la même version que celle que vous obtenez de l'EAR) devrait résoudre le problème.

Alternativement, isoler votre sous-déploiement du pot jackson présent dans l'EAR peut fonctionner, mais cela peut être compliqué avec les dépendances transitives. Voir chargement de classe dans Wildfly

EDIT comme vous l'avez confirmé, il existe deux versions différentes en cours d'exécution. Si vous pouvez vous le permettre, aligner les versions aiderait définitivement à résoudre le problème.

À part cela, vous devrez peut-être isoler chaque sous-déploiement afin qu'il ne voie que la version attendue. Voir cette réponse par exemple (qui isole l'ensemble du déploiement du module de base).

2
Guillaume 7 févr. 2020 à 13:38