[ http://jira.codehaus.org/browse/XFIRE-702?page=all ]
Dan Diephouse updated XFIRE-702:
--------------------------------
Fix Version/s: (was: 1.2.3)
Hmmm, spending some time looking into this and I don't really see how this can
happen. JAXB looks at the the namespacecontext of the XMLStreamReader. This
should contain the xsd namespace if it was declared.
Can you maybe use TCPMon to capture the whole message on the wire?
BTW, XSI spec is a high priority.
> jaxws xsd namespace declaration is not created on root elements of dispatched
> soap body content when ns prefix xsd is use INSIDE attribute value, eg
> xsi:type="xsd:int"
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: XFIRE-702
> URL: http://jira.codehaus.org/browse/XFIRE-702
> Project: XFire
> Issue Type: Bug
> Components: JAX-WS
> Affects Versions: 1.2.2
> Reporter: chris thatcher
> Assigned To: Dan Diephouse
> Priority: Blocker
>
> I am using XFire for my java ws stack solution and recently began using the
> JAXWSServiceFactory to resolve the namespace issues presented in XFIRE-582.
> Java to java communication through Xfire works great. However I use ZSI 2
> for a Python ws solution. ZSI serializes the objects to xml including the
> attribute xsi:type="xsd:int" or other xml shcema types. For example:
> <ns1:getVersionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:type="ns1:getVersionResponse"
> xmlns:ns1="http://www.emergent.net/2006/servertools/processmanagement";>
> <ns1:version
> xmlns:ns2="http://www.emergent.net/2006/servertools/processmanagement/model";
> authors="Chris Thatcher; Stephen Couratier" build="3" component="Agent"
> contact="[EMAIL PROTECTED]" license="http://www.emergent.com"; major="1"
> minor="2" product="Server" subProduct="Tools/ProcessManagement"
> xsi:type="ns2:version"/>
> <ns1:genericResponseHolder
> xmlns:ns2="http://www.emergent.net/2006/servertools/processmanagement/model";
> xsi:type="ns2:genericResponse">
> <ns2:responseCode xsi:type="xsd:int">1141</ns2:responseCode>
> <ns2:responseMessage xsi:type="xsd:string">Successfully Retreived the
> Versioning Information from the ProcessManagement Service
> Component</ns2:responseMessage>
> <ns2:fault xsi:type="xsd:boolean">false</ns2:fault>
> </ns1:genericResponseHolder>
> </ns1:getVersionResponse>
> This snippet is how the xml dom looks when logged at the 'pre-dispatch' phase
> of a Xfire client calling the ZSI python service. Note that the
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; is not present.
> It does appear on the SOAP Envelope:
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> <soap:Body>
> I am assuming it is not included in the xmlns declarations in the response
> element because it only appears inside the attribute values, and to be frank
> it actually suprised me it caused any sort of error. Unfortunately it does:
> org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested
> exception is org.codehaus.xfire.fault.XFireFault: prefix xsd is not bound to
> a namespace
> org.codehaus.xfire.fault.XFireFault: prefix xsd is not bound to a namespace
> at org.codehaus.xfire.fault.XFireFault.createFault(XFireFault.java:89)
> at org.codehaus.xfire.client.Client.onReceive(Client.java:386)
> at
> org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:139)
> at
> org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
> at
> org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
> at
> org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
> at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:75)
> at org.codehaus.xfire.client.Client.invoke(Client.java:335)
> at
> org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77)
> at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57)
> at $Proxy60.getVersion(Unknown Source)
> at
> net.emergent.www.servertools.processmanagement.client.impl.ProcessManagementClient.getVersion(ProcessManagementClient.java:162)
> at
> net.emergent.www.servertools.processmanagement.server.EmbeddedSMSServer.confirmResources(EmbeddedSMSServer.java:193)
> at
> net.emergent.www.servertools.processmanagement.server.EmbeddedSMSServer.init(EmbeddedSMSServer.java:162)
> at
> net.emergent.www.servertools.processmanagement.server.EmbeddedSMSServer.main(EmbeddedSMSServer.java:170)
> Caused by: java.lang.IllegalArgumentException: prefix xsd is not bound to a
> namespace
> at
> com.sun.xml.bind.DatatypeConverterImpl._parseQName(DatatypeConverterImpl.java:324)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.XsiTypeLoader.parseXsiType(XsiTypeLoader.java:52)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.XsiTypeLoader.startElement(XsiTypeLoader.java:30)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:369)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:347)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:35)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:201)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:135)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:337)
> at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:309)
> at org.codehaus.xfire.jaxb2.JaxbType.readObject(JaxbType.java:196)
> at
> org.codehaus.xfire.aegis.type.basic.HolderType.readObject(HolderType.java:43)
> at
> org.codehaus.xfire.aegis.AegisBindingProvider.readParameter(AegisBindingProvider.java:154)
> at
> org.codehaus.xfire.service.binding.AbstractBinding.read(AbstractBinding.java:206)
> at
> org.codehaus.xfire.service.binding.WrappedBinding.readMessage(WrappedBinding.java:50)
> at
> org.codehaus.xfire.jaxws.JAXWSOperationBinding.readMessage(JAXWSOperationBinding.java:149)
> at
> org.codehaus.xfire.soap.handler.SoapBodyHandler.invoke(SoapBodyHandler.java:42)
> at
> org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
> at org.codehaus.xfire.client.Client.onReceive(Client.java:382)
> ... 13 more
> I guess I'd expect to find the actual issue in SoapBodyHandler. I will look
> there now since this is a blocking issue for me. Thanks for any effort you
> can give this, I realize supporting the xsi spec probably low priority, but
> other services use it, and Jax-WS seems to be a stickler to the spec.
> XFire is an excellent product.
> Thanks,
> Thatcher
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
