You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Suneet Shah <su...@gmail.com> on 2009/08/07 00:08:02 UTC
SAXParseException: cos-nonambig Error
Hello
I am trying to build a service that combines types are in two different
name spaces: urn:oasis:names:tc:SPML:2:0 and
urn:oasis:names:tc:SPML:2:0:password. However, some of the complex types
refer to the same types. As I have things setup up right now with the
annotations, the wsdl that is being created is putting these in
different name spaces and causing the error below. My question is:
- What is good way to clean this up?
- Is there anything that I can do at the annotation level to avoid this
conflict?
I have attached the wsdl for reference.
thanks in advance for your help
Suneet
org.xml.sax.SAXParseException: cos-nonambig:
WC[##other:"urn:oasis:names:tc:SPML:2:0"] and
"urn:oasis:names:tc:SPML:2:0:password":psoID (or elements from their
substitution group) violate "Unique Particle Attribution". During
validation against this schema, ambiguity would be created for those two
particles.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at
com.sun.org.apache.xerces.internal.impl.xs.XSConstraints.reportSchemaError(XSConstraints.java:280)
at
com.sun.org.apache.xerces.internal.impl.xs.XSConstraints.fullSchemaChecking(XSConstraints.java:427)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:526)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:485)
at
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:210)
at
org.apache.cxf.wsdl.EndpointReferenceUtils.createSchema(EndpointReferenceUtils.java:633)
at
org.apache.cxf.wsdl.EndpointReferenceUtils.getSchema(EndpointReferenceUtils.java:655)
at
org.apache.cxf.interceptor.AbstractInDatabindingInterceptor.setSchemaInMessage(AbstractInDatabindingInterceptor.java:105)
.....
Aug 6, 2009 5:50:33 PM org.apache.cxf.wsdl.EndpointReferenceUtils
createSchema
WARNING: SAXException for newSchema() on
org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
'ns0:AddRequestType' to a(n) 'type definition' component.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaErr(XSDHandler.java:2541)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaError(XSDHandler.java:2528)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getGlobalDecl(XSDHandler.java:1472)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.traverseNamedElement(XSDElementTraverser.java:369)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.traverseLocal(XSDElementTraverser.java:179)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.traverseLocalElements(XSDHandler.java:2049)
at
com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:582)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:552)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:519)
Re: SAXParseException: cos-nonambig Error
Posted by Benson Margulies <bi...@gmail.com>.
And this one:
http://www.mail-archive.com/j-users@xerces.apache.org/msg02301.html
On Fri, Aug 7, 2009 at 6:49 PM, Benson Margulies<bi...@gmail.com> wrote:
> There's this thread:
>
> http://lists.xml.org/archives/xml-dev/200512/msg00277.html
>
> On Fri, Aug 7, 2009 at 12:13 PM, Daniel Kulp<dk...@apache.org> wrote:
>>
>> Honestly, I'm not sure what that error is supposed to mean.
>>
>> My suggestion would be to try and change the "ExtensibleType" to remove the
>> <xs:any> and <xs:anyAttribute> things temporarily and see if that fixes it.
>> My gut feeling is that it will. Two reasons:
>>
>> 1) Alll of the extensions of ExtensibleType also have xs:anyAttribute. Thus,
>> if an extra attribute is encountered, what happens?
>>
>> 2) The <xsd:any> would apply BEFORE the elements in the subclasses. If you
>> "merge" them into something that would look like whats on the wire, for
>> ExpirePasswordRequestType, its;
>>
>> <any ...../> (namespace when eval the ##other is
>> urn:oasis:names:tc:SPML:2:0)
>> <element name="psoID"/> (namespace on this is
>> urn:oasis:names:tc:SPML:2:0:password)
>>
>> Thus, an element on the wire of:
>> <psoID xmlns="urn:oasis:names:tc:SPML:2:0:password">...
>>
>> would match BOTH the xsd:any and the element definition. I think that's
>> where the error is coming from. There really isn't a consistent way to
>> "choose".
>>
>> Dan
>>
>>
>>
>> On Thu August 6 2009 6:08:02 pm Suneet Shah wrote:
>>> Hello
>>>
>>> I am trying to build a service that combines types are in two different
>>> name spaces: urn:oasis:names:tc:SPML:2:0 and
>>> urn:oasis:names:tc:SPML:2:0:password. However, some of the complex types
>>> refer to the same types. As I have things setup up right now with the
>>> annotations, the wsdl that is being created is putting these in
>>> different name spaces and causing the error below. My question is:
>>>
>>> - What is good way to clean this up?
>>> - Is there anything that I can do at the annotation level to avoid this
>>> conflict?
>>>
>>> I have attached the wsdl for reference.
>>>
>>> thanks in advance for your help
>>> Suneet
>>>
>>>
>>>
>>> org.xml.sax.SAXParseException: cos-nonambig:
>>> WC[##other:"urn:oasis:names:tc:SPML:2:0"] and
>>> "urn:oasis:names:tc:SPML:2:0:password":psoID (or elements from their
>>> substitution group) violate "Unique Particle Attribution". During
>>> validation against this schema, ambiguity would be created for those two
>>> particles.
>>> at
>>> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseE
>>>xception(ErrorHandlerWrapper.java:195) at
>>> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHand
>>>lerWrapper.java:131) at
>>> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>>>orReporter.java:384) at
>>> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>>>orReporter.java:318) at
>>> com.sun.org.apache.xerces.internal.impl.xs.XSConstraints.reportSchemaError(
>>>XSConstraints.java:280) at
>>> com.sun.org.apache.xerces.internal.impl.xs.XSConstraints.fullSchemaChecking
>>>(XSConstraints.java:427) at
>>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLS
>>>chemaLoader.java:526) at
>>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLS
>>>chemaLoader.java:485) at
>>> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSche
>>>ma(XMLSchemaFactory.java:210) at
>>> org.apache.cxf.wsdl.EndpointReferenceUtils.createSchema(EndpointReferenceUt
>>>ils.java:633) at
>>> org.apache.cxf.wsdl.EndpointReferenceUtils.getSchema(EndpointReferenceUtils
>>>.java:655) at
>>> org.apache.cxf.interceptor.AbstractInDatabindingInterceptor.setSchemaInMess
>>>age(AbstractInDatabindingInterceptor.java:105)
>>>
>>>
>>> .....
>>>
>>> Aug 6, 2009 5:50:33 PM org.apache.cxf.wsdl.EndpointReferenceUtils
>>> createSchema
>>> WARNING: SAXException for newSchema() on
>>> org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
>>> 'ns0:AddRequestType' to a(n) 'type definition' component.
>>> at
>>> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseE
>>>xception(ErrorHandlerWrapper.java:195) at
>>> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHand
>>>lerWrapper.java:131) at
>>> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>>>orReporter.java:384) at
>>> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>>>orReporter.java:318) at
>>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSche
>>>maErr(XSDHandler.java:2541) at
>>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSche
>>>maError(XSDHandler.java:2528) at
>>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getGlobalD
>>>ecl(XSDHandler.java:1472) at
>>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.t
>>>raverseNamedElement(XSDElementTraverser.java:369) at
>>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.t
>>>raverseLocal(XSDElementTraverser.java:179) at
>>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.traverseLo
>>>calElements(XSDHandler.java:2049) at
>>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchem
>>>a(XSDHandler.java:582) at
>>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSc
>>>hemaLoader.java:552) at
>>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLS
>>>chemaLoader.java:519)
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>
Re: SAXParseException: cos-nonambig Error
Posted by Benson Margulies <bi...@gmail.com>.
There's this thread:
http://lists.xml.org/archives/xml-dev/200512/msg00277.html
On Fri, Aug 7, 2009 at 12:13 PM, Daniel Kulp<dk...@apache.org> wrote:
>
> Honestly, I'm not sure what that error is supposed to mean.
>
> My suggestion would be to try and change the "ExtensibleType" to remove the
> <xs:any> and <xs:anyAttribute> things temporarily and see if that fixes it.
> My gut feeling is that it will. Two reasons:
>
> 1) Alll of the extensions of ExtensibleType also have xs:anyAttribute. Thus,
> if an extra attribute is encountered, what happens?
>
> 2) The <xsd:any> would apply BEFORE the elements in the subclasses. If you
> "merge" them into something that would look like whats on the wire, for
> ExpirePasswordRequestType, its;
>
> <any ...../> (namespace when eval the ##other is
> urn:oasis:names:tc:SPML:2:0)
> <element name="psoID"/> (namespace on this is
> urn:oasis:names:tc:SPML:2:0:password)
>
> Thus, an element on the wire of:
> <psoID xmlns="urn:oasis:names:tc:SPML:2:0:password">...
>
> would match BOTH the xsd:any and the element definition. I think that's
> where the error is coming from. There really isn't a consistent way to
> "choose".
>
> Dan
>
>
>
> On Thu August 6 2009 6:08:02 pm Suneet Shah wrote:
>> Hello
>>
>> I am trying to build a service that combines types are in two different
>> name spaces: urn:oasis:names:tc:SPML:2:0 and
>> urn:oasis:names:tc:SPML:2:0:password. However, some of the complex types
>> refer to the same types. As I have things setup up right now with the
>> annotations, the wsdl that is being created is putting these in
>> different name spaces and causing the error below. My question is:
>>
>> - What is good way to clean this up?
>> - Is there anything that I can do at the annotation level to avoid this
>> conflict?
>>
>> I have attached the wsdl for reference.
>>
>> thanks in advance for your help
>> Suneet
>>
>>
>>
>> org.xml.sax.SAXParseException: cos-nonambig:
>> WC[##other:"urn:oasis:names:tc:SPML:2:0"] and
>> "urn:oasis:names:tc:SPML:2:0:password":psoID (or elements from their
>> substitution group) violate "Unique Particle Attribution". During
>> validation against this schema, ambiguity would be created for those two
>> particles.
>> at
>> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseE
>>xception(ErrorHandlerWrapper.java:195) at
>> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHand
>>lerWrapper.java:131) at
>> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>>orReporter.java:384) at
>> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>>orReporter.java:318) at
>> com.sun.org.apache.xerces.internal.impl.xs.XSConstraints.reportSchemaError(
>>XSConstraints.java:280) at
>> com.sun.org.apache.xerces.internal.impl.xs.XSConstraints.fullSchemaChecking
>>(XSConstraints.java:427) at
>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLS
>>chemaLoader.java:526) at
>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLS
>>chemaLoader.java:485) at
>> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSche
>>ma(XMLSchemaFactory.java:210) at
>> org.apache.cxf.wsdl.EndpointReferenceUtils.createSchema(EndpointReferenceUt
>>ils.java:633) at
>> org.apache.cxf.wsdl.EndpointReferenceUtils.getSchema(EndpointReferenceUtils
>>.java:655) at
>> org.apache.cxf.interceptor.AbstractInDatabindingInterceptor.setSchemaInMess
>>age(AbstractInDatabindingInterceptor.java:105)
>>
>>
>> .....
>>
>> Aug 6, 2009 5:50:33 PM org.apache.cxf.wsdl.EndpointReferenceUtils
>> createSchema
>> WARNING: SAXException for newSchema() on
>> org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
>> 'ns0:AddRequestType' to a(n) 'type definition' component.
>> at
>> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseE
>>xception(ErrorHandlerWrapper.java:195) at
>> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHand
>>lerWrapper.java:131) at
>> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>>orReporter.java:384) at
>> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>>orReporter.java:318) at
>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSche
>>maErr(XSDHandler.java:2541) at
>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSche
>>maError(XSDHandler.java:2528) at
>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getGlobalD
>>ecl(XSDHandler.java:1472) at
>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.t
>>raverseNamedElement(XSDElementTraverser.java:369) at
>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.t
>>raverseLocal(XSDElementTraverser.java:179) at
>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.traverseLo
>>calElements(XSDHandler.java:2049) at
>> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchem
>>a(XSDHandler.java:582) at
>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSc
>>hemaLoader.java:552) at
>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLS
>>chemaLoader.java:519)
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: SAXParseException: cos-nonambig Error
Posted by Daniel Kulp <dk...@apache.org>.
Honestly, I'm not sure what that error is supposed to mean.
My suggestion would be to try and change the "ExtensibleType" to remove the
<xs:any> and <xs:anyAttribute> things temporarily and see if that fixes it.
My gut feeling is that it will. Two reasons:
1) Alll of the extensions of ExtensibleType also have xs:anyAttribute. Thus,
if an extra attribute is encountered, what happens?
2) The <xsd:any> would apply BEFORE the elements in the subclasses. If you
"merge" them into something that would look like whats on the wire, for
ExpirePasswordRequestType, its;
<any ...../> (namespace when eval the ##other is
urn:oasis:names:tc:SPML:2:0)
<element name="psoID"/> (namespace on this is
urn:oasis:names:tc:SPML:2:0:password)
Thus, an element on the wire of:
<psoID xmlns="urn:oasis:names:tc:SPML:2:0:password">...
would match BOTH the xsd:any and the element definition. I think that's
where the error is coming from. There really isn't a consistent way to
"choose".
Dan
On Thu August 6 2009 6:08:02 pm Suneet Shah wrote:
> Hello
>
> I am trying to build a service that combines types are in two different
> name spaces: urn:oasis:names:tc:SPML:2:0 and
> urn:oasis:names:tc:SPML:2:0:password. However, some of the complex types
> refer to the same types. As I have things setup up right now with the
> annotations, the wsdl that is being created is putting these in
> different name spaces and causing the error below. My question is:
>
> - What is good way to clean this up?
> - Is there anything that I can do at the annotation level to avoid this
> conflict?
>
> I have attached the wsdl for reference.
>
> thanks in advance for your help
> Suneet
>
>
>
> org.xml.sax.SAXParseException: cos-nonambig:
> WC[##other:"urn:oasis:names:tc:SPML:2:0"] and
> "urn:oasis:names:tc:SPML:2:0:password":psoID (or elements from their
> substitution group) violate "Unique Particle Attribution". During
> validation against this schema, ambiguity would be created for those two
> particles.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseE
>xception(ErrorHandlerWrapper.java:195) at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHand
>lerWrapper.java:131) at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>orReporter.java:384) at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>orReporter.java:318) at
> com.sun.org.apache.xerces.internal.impl.xs.XSConstraints.reportSchemaError(
>XSConstraints.java:280) at
> com.sun.org.apache.xerces.internal.impl.xs.XSConstraints.fullSchemaChecking
>(XSConstraints.java:427) at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLS
>chemaLoader.java:526) at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLS
>chemaLoader.java:485) at
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSche
>ma(XMLSchemaFactory.java:210) at
> org.apache.cxf.wsdl.EndpointReferenceUtils.createSchema(EndpointReferenceUt
>ils.java:633) at
> org.apache.cxf.wsdl.EndpointReferenceUtils.getSchema(EndpointReferenceUtils
>.java:655) at
> org.apache.cxf.interceptor.AbstractInDatabindingInterceptor.setSchemaInMess
>age(AbstractInDatabindingInterceptor.java:105)
>
>
> .....
>
> Aug 6, 2009 5:50:33 PM org.apache.cxf.wsdl.EndpointReferenceUtils
> createSchema
> WARNING: SAXException for newSchema() on
> org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
> 'ns0:AddRequestType' to a(n) 'type definition' component.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseE
>xception(ErrorHandlerWrapper.java:195) at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHand
>lerWrapper.java:131) at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>orReporter.java:384) at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErr
>orReporter.java:318) at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSche
>maErr(XSDHandler.java:2541) at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSche
>maError(XSDHandler.java:2528) at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getGlobalD
>ecl(XSDHandler.java:1472) at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.t
>raverseNamedElement(XSDElementTraverser.java:369) at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTraverser.t
>raverseLocal(XSDElementTraverser.java:179) at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.traverseLo
>calElements(XSDHandler.java:2049) at
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchem
>a(XSDHandler.java:582) at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSc
>hemaLoader.java:552) at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLS
>chemaLoader.java:519)
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog