[
https://issues.apache.org/jira/browse/TUSCANY-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611829#action_12611829
]
Scott Kurz commented on TUSCANY-2465:
-------------------------------------
Actually I found a 2nd problem with the new code. Actually the stack trace I
used when re-opening the JIRA was from a different test. When I retry my
original test (the itest/databinding/jaxb-bottom-up test), I actually fail
earlier with error:
---------
com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 1 counts of
IllegalAnnotationExceptions
Two classes have the same XML type name
"{http://jaxb.dev.java.net/array}base64BinaryArray";. Use @XmlType.name and
@XmlType.namespace to assign different names to them.
this problem is related to the following location:
at javax.xml.transform.Source[]
this problem is related to the following location:
at javax.activation.DataHandler[]
at
com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:66)
at
com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:422)
at
com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:270)
at
com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:103)
at
com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:81)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:599)
at
com.ibm.xml.xlxp2.jaxb.JAXBContextImpl.createFallbackContext(JAXBContextImpl.java:243)
at
com.ibm.xml.xlxp2.jaxb.JAXBContextImpl.<init>(JAXBContextImpl.java:130)
at
com.ibm.xml.xlxp2.jaxb.JAXBContextFactory.createContext(JAXBContextFactory.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:599)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:211)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:372)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getJAXBContext(JAXBContextCache.java:270)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:179)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:211)
at
org.apache.tuscany.sca.databinding.jaxb.JAXBTypeHelper.getSchemaDefinitions(JAXBTypeHelper.java:227)
at
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:212)
at
org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:193)
---------
Note this is on a Java V6 JRE... also, though it uses IBM XLXP it seems to
defer to the Sun RI JAXB impl (not sure exactly why).
> 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.
