[ http://jira.codehaus.org/browse/XFIRE-702?page=comments#action_80232 ] chris thatcher commented on XFIRE-702: --------------------------------------
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="[EMAIL PROTECTED]" 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 > 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
