J'essaie de désérialiser un objet JSON stocké dans CouchDb en utilisant Jackson. Cet objet doit être désérialisé dans un pojo qui contient des méthodes surchargées. Lorsque j'essaie de récupérer l'objet dans Couch et de procéder à la désérialisation, j'obtiens l'exception suivante :
org.ektorp.DbAccessException : org.codehaus.jackson.map.JsonMappingException : Définitions de setter contradictoires pour propriété "multiplier" : com.db.commodities.framework.sdos.model.security.EqOpt#setMultiplier(1 params) vs com.db.commodities.framework.sdos.model.security.EqOpt#setMultiplier(1 paramètres)
J'ai essayé d'annoter le setter que je voudrais que Jackson utilise, mais cela ne semble pas avoir fonctionné.
@JsonProperty("multiplier")
public void setMultiplier(SDOSAttribute multiplier) {
this.multiplier = multiplier;
}
public void setMultiplier(double multiplier) {
this.multiplier.setValue(String.valueOf(multiplier));
}
Comment puis-je configurer Jackson pour qu'il désérialise correctement en utilisant une méthode spécifique ? Ou est-ce que j'aborde ce problème de la mauvaise façon ?
EDIT :
J'ai apporté les modifications suivantes. Cela semble fonctionner, mais c'est un peu plus laid. Si quelqu'un a une meilleure façon de procéder, n'hésitez pas à la partager et je l'accepterai volontiers.
@JsonProperty("multiplier")
protected void setMultiplierAttribute(SDOSAttribute multiplier) {
this.multiplier = multiplier;
}
@JsonIgnore
public void setMultiplier(double multiplier) {
this.multiplier.setValue(String.valueOf(multiplier));
}
0 votes
Oui, c'est une solution valable. Je suis d'accord sur le fait que ce serait bien si l'inférence était utilisée de telle sorte que si une seule alternative était explicitement indiquée, les autres pourraient être ignorées en cas d'ambiguïté de la surcharge -- je peux ajouter une demande de fonctionnalité Jira pour cela.
0 votes
Autre chose : il est intéressant que le problème de la surcharge se pose ici, puisque Jackson autorise en fait une surcharge limitée. Plus précisément, si l'argument était int ou long (au lieu de double), le problème ne se poserait pas. Mais les autres types primitifs (double, float, boolean, char, byte, short) ne sont pas supportés de cette manière ; bien que float et double devraient probablement l'être. Avec int et long, la différence est résolue sur la base de ce que JSON a -- les objets JSON utilisent le setter POJO ; JSON numérote int ou long.