[
https://issues.apache.org/jira/browse/TUSCANY-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612407#action_12612407
]
Simon Nash commented on TUSCANY-2465:
-------------------------------------
Thanks for this code, which has helped me understand what is causing the
problem. The duplicate loadXSD() calls for the same schema TNS will occur in
either of the following cases:
1. An XMLTypeHelper returns schema definitions for some application types, and
Interface2WSDLGenerator creates wrappers in the same namespace as those
application types.
2. An XMLTypeHelper returns schema definitions for some wrappers, and
Interface2WSDLGenerator creates wrappers in the same namespace as those
wrappers.
The fix that Raymond checked in works because it gives unique IDs to the
XSDefinition objects for the wrappers created by Interface2WSDLGenerator, thus
preventing a clash with any XSDefinition objects for schemas returned by an
XMLTypeHelper.
It isn't actually necessary to give unique IDs to different XSDefinition
objects for the wrappers created by Interface2WSDLGenerator, because the clash
is not between different instances of these objects. Any value that's non-null
would be enough to prevent the clash between these objects and the XSDefinition
objects created by the XMLTypeHelper.
This area could be revisited if/when the XMLTypeHelper code is changed to
import from existing schemas in the contribution rather than copying them
inline. I think this will require helpers that do this to set a non-null
location value in the XSDefinition objects that they create. If the helpers
were to always set a non-null unique location value in these XSDefinition
objects, there would be no need for Interface2WSDLGenerator to set a non-null
location valuein the XSDefinition objects that it creates for generated
wrappers.
> 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
> Fix For: Java-SCA-1.3
>
> Attachments: 2465.hacked.test.diff
>
>
> 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.