Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
Roughly SCA Java 1.3
Description
When trying the equivalent of the itest/databindings/jaxb-bottom-up test with a newer version of XMLSchema (newer than the 1.3.2 version Tuscany depends on), I hit an error
org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in collection. Namespace: http://jaxb.dev.java.net/array
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:104)
at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:83)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:424)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:418)
at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.loadXSD(Interface2WSDLGenerator.java:354)
at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.addSchemaExtension(Interface2WSDLGenerator.java:336)
at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:213)
The problem lies in Interface2WSDLGenerator.generate(), with this excerpt:
for (Map.Entry<String, List<DataType>> en: getDataTypes(interfaze, false).entrySet()) {
XMLTypeHelper helper = helpers.get(en.getKey());
if (helper == null)
List<XSDefinition> xsDefinitions = helper.getSchemaDefinitions(xsdFactory, resolver, en.getValue());
for (XSDefinition xsDef: xsDefinitions)
}
The getDataTypes(interfaze,false) does its introspection of the DataType(s) and returns a pair of Map.Entry(s). One has key: simpleType, and one has key: complexType. For each of these keys, the call to helpers.get(en.getKey()) returns the JAXTypeHelper, and each results into addSchemaExtension() which in turn calls loadXSD() which I showed in the stack trace. And the problem is each call involves an XMLSchema def with the same TNS, http://jaxb.dev.java.net/array.
Somehow we need to reduce this to one call to SchemaBuilder or we'll break this test when we upgrade our XMLSchema dependency. (Not sure what if anything is broken on this level of XMLSchema since the 2nd call ends up as a no-op).