2012-01-05 4 views
13

Je rencontre un problème avec JAXB unmarshalling. Je pense que je l'ai correctement codé, mais mon objet unmarshalled retourne avec des paramètres null. Par conséquent, je suppose que lorsque JAXB ne vérifie pas, il ne voit pas la structure XML appropriée qu'il attend. Cependant, je ne reçois aucun message d'erreur ou aucune exception levée. Y at-il de toute façon un pas à faire dans le processus de désassemblage pour voir exactement où/pourquoi il ne remplit pas mes objets?Comment déboguer JAXB unmarshalling?

Le code unmarshalling réelle est assez banale:

public <T> T unmarshall(Node node, Class<T> clazz) throws JAXBException { 
    // Creating an unmarshaller 
    Unmarshaller u = JAXBContext.newInstance(clazz).createUnmarshaller(); 

    // unmarshal an instance node into Java content 
    return clazz.cast(u.unmarshal(node, clazz).getValue()); 
} 

Cependant, quand je l'appelle, je reçois un objet de type clazz est revenu (comme prévu), mais dépeuplé.

L'objet DOM que j'essaie de démarester est généré par une API tierce. J'ai déjà rencontré des comportements extrêmement bizarres avec l'unmarshalling, c'est pourquoi je voudrais pouvoir déboguer le processus. Par exemple, si j'essaie de démélanger un sous-élément dans l'objet DOM (ie: doc.getByElementName ("myElement"). Item (0)), il échoue silencieusement. Toutefois, si je convertis le document en chaîne et que je le réimprime dans un nouveau document, il le convertit correctement. Je commence à être très frustré de ne pas savoir comment déboguer ce problème.

Merci pour toute idée!

Eric

Répondre

7

Une approche que vous pourriez prendre est d'utiliser JAXB pour générer un schéma XML de vos classes annotées. Cela représente ce que JAXB attend du document d'entrée. Ensuite, validez votre document XML par rapport à ce schéma XML pour voir s'il est conforme aux attentes de JAXB.

+0

Merci pour le lien. Je n'ai jamais essayé ça avant; va lui donner un coup de feu. Mais étant donné que j'ai généré les classes JAXB à partir d'un XSD, il semble que l'on puisse revenir en arrière. Mais je ne trouve toujours pas que ce soit une solution élégante. JAXB agit comme une boîte noire complète, et sans aucun indicateur expliquant ce qu'il fait, je n'ai aucune idée de quoi-si-jamais pourquoi il échoue. J'aimerais trouver une méthode pour me permettre de «voir» ce qu'il fait et/ou où se trouvent les problèmes. –

+0

Merci pour la suggestion. J'ai essayé d'utiliser le validateur, et il lance une erreur que je ne comprends pas. J'ai créé un fil séparé pour cela (http://stackoverflow.com/questions/8761930/jaxb-unmarshal-validation-throws-cvc-elt-1-cannot-find-the-declaration-of-eleme). Si vous pouvez suggérer quelque chose, je l'apprécierais grandement. Merci. –

+0

En effet, c'est la meilleure approche que j'ai trouvée jusqu'ici parce que [d'autres approches] (http://stackoverflow.com/a/10227684/1864054) ne donnent simplement pas de bons résultats et/ou productifs. Cependant, je recommande de ne pas utiliser soapUI pour générer des messages de test car il génère un squelette de message sans fausse valeur de données, ce qui vous oblige à taper manuellement tout ce qui est sujet aux erreurs, en particulier pour les gros messages. Au lieu de cela, XMLSpy d'Altova fonctionne à merveille. Tout ce que vous avez à faire est de sélectionner l'item 'Créer une nouvelle requête SOAP 'dans le menu' SOAP' et, voila !, vous avez un message (fake) parfaitement fonctionnel – Withheld

10
JAXBContext context = JAXBContext.newInstance(jaxbObjectClass); 
Unmarshaller unmarshaller = context.createUnmarshaller(); 
unmarshaller.setEventHandler(new javax.xml.bind.helpers.DefaultValidationEventHandler()); 
+1

Un commentaire ou deux sur la façon dont cet extrait de code répond à la question DefaultValidationEventHandler est l'ancien gestionnaire JAXB 1.0 - est-ce que vous suggérez ceci comme réponse parce que l'ancien gestionnaire cracherait plus de messages d'erreur verbeux? – Ryan

+0

De la javadoc: public class DefaultValidationEventHandler extends Object implémente ValidationEventHandler JAXB 1.0 uniquement gestionnaire d'événements de validation par défaut. C'est le gestionnaire par défaut pour tous les objets créés à partir d'un JAXBContext qui gère le code dérivé du schéma généré par un compilateur de liaison JAXB 1.0. Ce gestionnaire provoque l'échec des opérations non valides et de validation lors de la première erreur ou de l'erreur fatale. – superbAfterSemperPhi