JAXB xsd:inclure et les packages séparés

Question

J'ai la situation suivante :

Il y a 2 fichiers xsd. Le premier définit un élément racine, et plusieurs types.

Le deuxième inclut le premier, et étend un des types. Il n'y a pas de type racine défini dans ce fichier.

À partir du premier xsd, un modèle est généré dans un package (a). Le deuxième schéma devrait créer un nouveau package (b) pour les types supplémentaires, mais réutiliser le package généré a. J'ai résolu cela en utilisant un fichier de liaison qui pointe vers les éléments précédemment générés (dans le package a). Jusqu'à présent, cela fonctionne, mais...

JAXB génère un ObjectFactory dans le package A, contenant une méthode create pour l'élément racine. Pour le deuxième schéma, un ObjectFactory est également créé dans le package B. Et cette classe a également la méthode create pour le même élément racine.

Pour pouvoir utiliser tous les types, le contexte jaxb est créé en utilisant plusieurs factories d'objets (newInstance(a.ObjectFactory.class, b.ObjectFactory.class)).

À l'exécution, cela se traduit par l'erreur suivante :

 

com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 2   violations de IllegalAnnotationExceptions   Le nom de l'élément {http://www.example.org/Scenario/}scenario a plus   d'un mappage

Dois-je générer les packages différemment ? Ou est-il possible d'utiliser le fichier de liaison pour empêcher l'object factory d'avoir des méthodes en double ?

Answer 1

Tout d'abord, il est important de comprendre que si vous utilisez xsd:include au lieu de xsd:import, vous n'avez pas deux schémas différents. C'est un seul schéma dans plusieurs fichiers et le compiler dans plusieurs packages et de tromper JAXB pour combiner ces packages ressemble plus à du piratage.

Ma suggestion principale serait donc d'utiliser xsd:import à la place et de considérer l'approche compilation de schéma séparée.

Si vous souhaitez rester avec xsd:include, vous devrez tromper JAXB. Par exemple, vous pouvez supprimer ou ajuster l'une (ou les deux) des classes ObjectFactory et construire votre contexte JAXB basé sur des classes individuelles plutôt que des fabriques d'objets. Vous pouvez également utiliser jaxb.index au lieu des fabriques d'objets. Mais c'est du piratage.