XFire

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"

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Blocker Blocker
  • Resolution: Unresolved
  • Affects Version/s: 1.2.2
  • Fix Version/s: None
  • Component/s: JAX-WS
  • Labels:
    None
  • Number of attachments :
    0

Description

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="chris.thatcher@emergentgametech.com" 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

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dan Diephouse added a comment -

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.

Show
Dan Diephouse added a comment - 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.
Hide
Permalink
chris thatcher added a comment -

Hi Dan, I will run the service with tcpmon today to get a full dump of what comes across the wire. The important thing to note thouough is that I can already see from the logging handler that the SOAP Envelope does in fact have the xsd namespace prefix defined:

<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>
...

So my assumption was that a new XMLStreamReader was created for the contents of the SOAP Body (to pass that stream reader to jaxb)and that's why the prefix was not defined (below is the element inside the soap body): <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 ...

Is it at all possible that having the DomIn/OutHandler's defined change the underlying treatment of how the XMLStreamReader is created? If you point me at the class you suspect Ill try to debug as well and see if I can learn anything from a step through.

Thatcher

Show
chris thatcher added a comment - Hi Dan, I will run the service with tcpmon today to get a full dump of what comes across the wire. The important thing to note thouough is that I can already see from the logging handler that the SOAP Envelope does in fact have the xsd namespace prefix defined: <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> ... So my assumption was that a new XMLStreamReader was created for the contents of the SOAP Body (to pass that stream reader to jaxb)and that's why the prefix was not defined (below is the element inside the soap body): <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 ... Is it at all possible that having the DomIn/OutHandler's defined change the underlying treatment of how the XMLStreamReader is created? If you point me at the class you suspect Ill try to debug as well and see if I can learn anything from a step through. Thatcher
Hide
Permalink
chris thatcher added a comment -

Sorry it took me a whole day to get this done, but here is the tcpmon capture of the response from a zsi service:

HTTP/1.0 200 OK
Server: ZSI/1.1 BaseHTTP/0.3 Python/2.4.2
Date: Wed, 15 Nov 2006 14:56:33 GMT
Content-type: text/xml; charset="utf-8"
Content-Length: 1210

<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ZSI="http://www.zolera.com/schemas/ZSI/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SOAP-ENV:Header></SOAP-ENV:Header><SOAP-ENV:Body xmlns:ns1="http://www.emergent.net/servertools/processmanagement"><ns1:getVersionResponse xmlns:ns2="http://www.emergent.net/www/servertools/common/model" xsi:type="ns1:getVersionResponse"><ns1:version authors="Chris Thatcher; Stephen Couratier" build="3" component="Orchestrator" contact="chris.thatcher@emergentgametech.com" license="http://www.emergent.com" major="1" minor="2" product="Server" subProduct="Tools/ProcessManagement" xsi:type="ns2:version"></ns1:version><ns2:genericResponse 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></ns2:genericResponse></ns1:getVersionResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>

Thatcher

Show
chris thatcher added a comment - Sorry it took me a whole day to get this done, but here is the tcpmon capture of the response from a zsi service: HTTP/1.0 200 OK Server: ZSI/1.1 BaseHTTP/0.3 Python/2.4.2 Date: Wed, 15 Nov 2006 14:56:33 GMT Content-type: text/xml; charset="utf-8" Content-Length: 1210 <SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ZSI="http://www.zolera.com/schemas/ZSI/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SOAP-ENV:Header></SOAP-ENV:Header><SOAP-ENV:Body xmlns:ns1="http://www.emergent.net/servertools/processmanagement"><ns1:getVersionResponse xmlns:ns2="http://www.emergent.net/www/servertools/common/model" xsi:type="ns1:getVersionResponse"><ns1:version authors="Chris Thatcher; Stephen Couratier" build="3" component="Orchestrator" contact="chris.thatcher@emergentgametech.com" license="http://www.emergent.com" major="1" minor="2" product="Server" subProduct="Tools/ProcessManagement" xsi:type="ns2:version"></ns1:version><ns2:genericResponse 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></ns2:genericResponse></ns1:getVersionResponse></SOAP-ENV:Body></SOAP-ENV:Envelope> Thatcher

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.