2017-06-20 3 views
1

J'ai 3 XSD reliés entre eux:MOXY- XSD multiples importer le même schéma definition- erreur: « élément » est déjà défini

schema1.xsd 
    imports namespace="x:y:z" schemaLocation= "schemaDefinitions.xsd" 
    includes schema2.xsd 
schema2.xsd 
    imports namespace="x:y:z" schemaLocation= "schemaDefinitions.xsd" 
    includes schema3.xsd 
schema3.xsd 
    imports namespace="x:y:z" schemaLocation= "schemaDefinitions.xsd" 

Ces XSD sont fournis par une source extérieure et ne peuvent pas être modifiés.

Auparavant, mon projet utilisait JAXB standard avec des classes créées au moment de la compilation. Je change actuellement dynamique JAXB MOXY (exécution) et reçois maintenant l'erreur suivante sur ma ligne DynamicJAXBContextFactory.createContextFromXSD(), qui utilise Schema1.xsd pour FileInputStream:

Exception in thread "main" java.lang.ExceptionInInitializerError at 
    TestTool.JavaRoot.TestTools.MainTool.main(MainTool.java:55) 
    Caused by: Exception [EclipseLink-50040] (Eclipse Persistence Services - 
    2.6.2.v20151217-774c696): 
    org.eclipse.persistence.exceptions.JAXBException 
Exception Description: Error creating DynamicJAXBContext. 
    Internal Exception: org.xml.sax.SAXParseException; systemId: 
    file:///public/SITE1/config/schema/SchemaDefinitions.xsd; lineNumber: 
    xyz; columnNumber: xyz; 'xyz' is already defined 

J'ai déterminé la cause est le fait que les trois schémas importent schemaDefinitions.xsd. Si je supprime l'instruction import de schema2 et schema3, l'erreur est résolue. Cette erreur n'était pas présente avec l'implémentation précédente de jaxb et les xsds n'ont pas changé depuis le passage à MOXY.

Questions:

  1. Est-il légal/valable pour les XSD à importer/inclure dans cette façon

  2. Quels sont possibles contournements de travail puisque je ne peux pas modifier les XSD? Peut-être des modifications au fichier xjb de liaisons?

Répondre

1

Problème résolu en désactivant vérification d'erreur avec mettre la ligne suivante en classe MyEntityResolver.java:

System.setProperty("com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.noCorrectnessCheck", "true"); 

J'avais essayé dans ma classe principale java avant, apparemment des thats au mauvais endroit pour elle!

+0

Content que vous ayez réussi à résoudre votre problème. Si jamais vous déterminez une solution qui permet toujours la validation, veuillez mettre à jour votre réponse. Merci. – kjhughes

1

Une autre answerer peut être en mesure d'aider directement avec un support de configuration Moxy dans le domaine des déclarations en double, mais uniquement le niveau XSD:

  1. Malheureusement, la recommandation du W3C XSD permet un comportement dépendant de la mise en œuvre se produire lorsqu'un XSD est importé plusieurs fois. (Voir la dernière note dans 4.2.3 References to schema components across namespaces)
  2. Selon le processeur XSD sous-jacent sur lequel MOXy est construit, vous pouvez définir un indicateur pour autoriser/interdire plusieurs importations. Pour Xerces, voir honour-all-schemaLocations; pour Saxon, voir multipleSchemaImports.

Voir aussi Is it an error to import the same XSD multiple times?


Note a pending improvement sur la sémantique de multipleSchemaImports.

+0

Merci, cela me donne certaines choses à regarder. Malheureusement, MOXY ne semble pas avoir beaucoup de disciples pour aider. Peut-être que je mettrais ce drapeau saxon dans mon EntityResolver? Les exemples trouvés avec moxy ne semblent pas couvrir ce problème. J'ai également joué avec le drapeau noCorrectnessCheck (montré à: http://www.eclipse.org/eclipselink/documentation/2.5/solutions/jpatoxml006.htm) mais cela n'a pas semblé aider beaucoup – JavaBeast

+0

'honor-all-schemaLocations' et' multipleSchemaImports' sont généralement définis via un fichier de configuration de l'analyseur, un commutateur de ligne de commande ou éventuellement un paramètre API. – kjhughes

+0

hmm je ne sais pas vraiment comment l'appliquer à la terminologie MOXY, tout cela est nouveau pour moi. À ce stade, je suis à moitié tenté de lire le fichier et de supprimer les lignes d'importation à la main. Mais c'est tellement très hackish je ne pourrais probablement pas vivre avec moi-même – JavaBeast