[
https://issues.apache.org/jira/browse/TUSCANY-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz reopened TUSCANY-2465:
---------------------------------
Thanks for the quick patch, but unfortunately this just postpones the problem a
bit.
I now hit the problem after building the wrapperXSDs XSDefinitions:
// resolve XSDefinitions containing generated wrappers
for (XSDefinition xsDef: wrapperXSDs.values()) {
loadXSD(schemaCollection, xsDef);
wsdlDefinition.getXmlSchemas().add(xsDef);
}
My stack trace (for what it's worth, you can see I'm using the old path name
for the generator):
Caused by: org.apache.ws.commons.schema.XmlSchemaException: Schema name
conflict in collection. Namespace: http://blah
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:355)
at
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:303)
at
org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:193)
> J2W Interface2WSDLGenerator should only call SchemaBuilder once per TNS
> -----------------------------------------------------------------------
>
> Key: TUSCANY-2465
> URL: https://issues.apache.org/jira/browse/TUSCANY-2465
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Data Binding Runtime
> Environment: Roughly SCA Java 1.3
> Reporter: Scott Kurz
> Assignee: Raymond Feng
>
> 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) {
> continue;
> }
> List<XSDefinition> xsDefinitions =
> helper.getSchemaDefinitions(xsdFactory, resolver, en.getValue());
> for (XSDefinition xsDef: xsDefinitions) {
> addSchemaExtension(xsDef, schemaCollection, wsdlDefinition,
> definition);
> }
> }
> 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).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
