7
votes

Problème de sérialisation / désérialisation du maillot: Les types d'abstrait ne peuvent être instanciés que d'informations de type supplémentaires.

J'utilise Jersey pour la sérialisation et la désérialisation. J'ai fait canal de repos sur Weblogic avec Jersey. J'ai un objet de résultat avec contient une classe abstraite. Jersey ajoute aux métadonnées de résultat avec ce nom de mise en œuvre de classe: xxx pré>

Cependant, le même maillot, lorsque vous utilisez pour désérialiser ces données, hurle les éléments suivants: P>

private static Client client;

private static void initClient() {
    if (client == null) {
        ClientConfig clientConfig = new DefaultClientConfig();
        clientConfig.getFeatures().put(JSONConfiguration.FEATURE_POJO_MAPPING,
                Boolean.TRUE);
        client = Client.create(clientConfig);
    }
}

private static <T> T jsonForResult(String addr, Class<T> expectedClass) {
    initClient();
    WebResource r = client.resource(addr);
    try {
        T result = r.get(expectedClass);
    return result;
        } catch (UniformInterfaceException e) {
        log.error(e.getMessage(), e);
        return null;
    }
}


0 commentaires

3 Réponses :


6
votes

Jersey (ou plus précisément, Jackson Json Lib utilise avec le mappage de pojo) n'ajouter pas @type sauf si l'inclusion des informations de type n'est activée, généralement en ajoutant @jsontypeinfo sur un type de résumé. Donc, quelque chose doit avoir activé cela. Peut-être que vous pouvez partager la définition détaillant classe?

sur le problème lui-même: Ceci est généralement causé par des types incompatibles utilisés - type utilisé pour la désérialisation (la lecture de la valeur JSON dans POJO) doit être telle que @jsontypeInfo annotation est visible. Vous ne pouvez pas, par exemple, demander une valeur de type java.lang.Object , car il n'a pas une telle annotation. Sans connaître les définitions de classe réelles, il n'est pas possible de pointer vers une cause spécifique, mais c'est l'explication la plus probable.


4 commentaires

Je suis à l'aide de @xmleealso pour spécifier toutes les classes héritantes (15 :-), sans sérialiser causé une erreur. Peut-être que Weblogic ajoutez quelque chose, je ne sais pas Weblogic, je dois juste m'intégrer avec un projet malheureusement fait pour lui.


Ah. Oui, @xmsealso est probablement traduit en équivalent de @jsontypeinfo . C'est bien - il doit également être visible de manière similaire. Il est également possible que Jaxb annotation Introspector extension (c'est un complément de Jackson) pourrait avoir un bug ici. Une possibilité est d'essayer d'utiliser Jackson comme étant autonome en premier, de voir si les choses fonctionnent en dehors de Weblogic et, selon la manière dont cela va, trouvez la solution appropriée.


J'ai fusionné les 15 cours dans une DTO, alors le premier problème est absent. Mais la classe contient des listes d'objets, et pour ces balises @type ne sont pas générées, la désérialisation échoue également.


Vous devez également annoter des propriétés - @jsontypeinfo n'est pas transitif (bien qu'il s'applique au contenu des listes, lorsqu'il est appliqué à une propriété de liste).



12
votes

Essayez Ce Cela fonctionne

@XmlSeeAlso({ExchangeFormat.class,TypeStatus.class})


1 commentaires

Le lien fourni ne peut plus être consulté.



1
votes

Si vous voulez simplement exclure simplement le champ type , annotation de la superclasse @xmlTransient , comme mentionné ici: http://blog.bdoughan.com/2011/06/IGNOGE-Inheritance-with-xmlTransient.html < / p>

qui rendra la sérialisement fonctionnera comme si les champs de superclasse étaient dans la classe enfant - donc comme s'il n'y avait pas de héritage, auquel cas le champ type ne sera pas produit.


0 commentaires