Dev Faq
9
votes

JAXB 2.x: Comment mousser un XML sans connaître la classe cible?

S'il y a un moyen, comment faire cela, j'aimerais connaître le plus élégant. Voici la question: - supposons que vous avez une classe abstraite z - Vous avez deux classes héritées de z: nommée A et B.

Vous êtes un maréchal toute instance (A ou B) comme ceci: p> xxx pré>

dans le XML résultant que vous voyez Quel genre d'instance c'était (A ou B). P>

MAINTENANT, comment êtes-vous démarré comme P> 

"Exception Description: A descriptor with default root element {<my namespace>}<the root tag, e.g. A or B> was not found in the project]

0 commentaires

4 Réponses :

0
votes

Chaque Les documents XML doivent avoir un élément racine et si vous souhaitez utiliser le même Motemaaller pour les deux instances Votre seule possibilité est d'avoir un élément racine commun tel que: xxx

et votre fichier xsd ressemblerait à ce xxx

3 commentaires

Je viens de l'essayer, ne fonctionne pas. Le MemaShaller ne peut pas ne pas mousser. Il est indiqué: "Cette classe ne définit pas un constructeur par défaut public ou le constructeur a soulevé une exception." Bien sûr, la classe abstraite Z ne peut pas être instanciée. Ce que j'attends, c'est que le MemaShall détecte les informations de type d'instance dans le XML et la MODARSHALL à l'objet correct.

Il y a une question similaire et je teste maintenant cette réponse: lien

Cette réponse ne résout pas le problème. Je n'utilise pas non plus XSD du tout. Juste pojo <> Jaxb <> XML.

4
votes

Il y a une question similaire ici A > > SenderPerson.class code>? P> 

@XmlRootElement(name="person")
public class ReceiverPerson extends Person {
  // receiver specific code
}

@XmlRootElement(name="person")
public class SenderPerson extends Person {
  // sender specific code (if any)
}

// note: no @XmlRootElement here
public class Person {
  // data model + jaxb annotations here
}

1 commentaires

De toute évidence, vous devez toujours fournir une liste de classes que le Mobilehaller peut utiliser comme classe cible, mais cela brise toute l'approche OO, vous n'avez pas besoin de mentionner toutes les sous-classes possibles!

1
votes

Il n'y a pas de solution à ma question!

Dans toutes les circonstances, vous devez dire à l'UNMARSHALLER exactement quel objet il devrait se déshabiller.

1 commentaires

Votre affirmation selon laquelle le Mobilehaller nécessite que la connaissance du type cible n'est pas correcte. Dans l'exemple de code par Alex, dès que le MODAALSHALLER a attribué une valeur à OOO, l'objet mentionné par OOO est déjà une instance de la classe cible. La manière dont vous choisissez de jeter cette instance est à vous que la liste des sous-classes éligibles est potentiellement infinie, dont la sélection est presque certainement soumise à la logique définie des entreprises.

0
votes

Alors, comment allez-vous alors que vous obtenez une instance de z, puis vous pouvez tester> après la déshabillage, ce que c'est? par exemple. Z Système d'achiose A alors ... une instance Z de B. Quelque chose d'autre ... etc.

Cela devrait fonctionner ... xxx

J'ai testé cela moi-même et ça marche.

1 commentaires

C'est bien, mais pas assez bon. Disons qu'un jour vous introduisez la classe C, et même plus tard, peut-être que D. existe-t-il une solution où vous n'avez pas à mettre à jour votre section de code ci-dessus? Il devrait fonctionner automatiquement avec toutes les sous-classes ...

Articles qui pourrait vous intéresser :

Comment envoyer une liste vide à la clause IN
Code de réponse 403 inattendu lors de la récupération des données des API
Impossible de trouver la classe UnityPlayerActivity dans com.unity3d.player
Comment définir un tableau dans jsonobject