Hi Manolo, I have a bug opened for this already:) MUSE-239: response name should come from the wsdl
-----Original Message----- From: Manolo Gomez Lopez [mailto:[EMAIL PROTECTED] Sent: Monday, September 10, 2007 4:16 AM To: [email protected] Subject: Response element's name in SOAP Message in Apache Muse Hi, Having a look at how Apache Muse generates a response for a given request, one can state that it is generating the XML response under soap:body using org.apache.muse.core.routing.ReflectionMessageHandler.toXML() (in the standard configuration). There, Apache Muse asks the resource for the implementation of the capability and serializes the response for XML embedding in the SOAP response message. Before that, the name of the XML element to embed in the response is generated using org.apache.muse.core.routing.AbstractMessageHandler.createResponseName() : private QName createResponseName() { QName request = getRequestName(); String uri = request.getNamespaceURI(); String name = request.getLocalPart(); String prefix = request.getPrefix(); return new QName(uri, name + "Response", prefix); } Here we can see that Apache Muse adds the suffix "Response" to the LocalPart of the operation requested and so the xml is generated. Here we have an example, the operation is named "GetArticulos", this is the request: <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope";> <soap:Header> <wsa:To xmlns:wsa="http://www.w3.org/2005/08/addressing";> http://192.168.200.128:8080/MyService/services/MyService</wsa:To> <wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing";> http://test/services/MyService/GetArticulos</wsa:Action> <wsa:MessageID xmlns:wsa="http://www.w3.org/2005/08/addressing ">uuid:394f2630-ba3c-14e7-faad-e7c34225deaf</wsa:MessageID> <wsa:From xmlns:wsa="http://www.w3.org/2005/08/addressing";> <wsa:Address>http://www.w3.org/2005/08/addressing/role/anonymous </wsa:Address> </wsa:From> </soap:Header> <soap:Body> <pfx0:getArticulos xmlns:pfx0="http://test/services/MyService";> <pfx0:idArticulo>1</pfx0:idArticulo> <pfx0:idProveedor>2</pfx0:idProveedor> <pfx0:idProducto>3</pfx0:idProducto> <pfx0:nombreArticulo>nombreArticulo</pfx0:nombreArticulo> <pfx0:tipoCodificacion>tipoCodificacion</pfx0:tipoCodificacion> <pfx0:valorCodificacion>valorCodificacion</pfx0:valorCodificacion> <pfx0:detalles>true</pfx0:detalles> </pfx0:getArticulos> </soap:Body> </soap:Envelope> And this is the response (only the tricky part): <soapenv:Body> <muse-op:getArticulosResponse xmlns:muse-op=" http://test/services/MyService"; xmlns:tns=" http://axis2.platform.core.muse.apache.org";> <muse-op:Mensaje> <soy> <un> <equisemeele/> </un> </soy> </muse-op:Mensaje> </muse-op:getArticulosResponse> </soapenv:Body> Where we can see it's generating "getArticulosResponse" as the root element of the XML response. If we generate proxy client code for the same WSDL we can see that it is generating an array of response names, and here is where the problems begin, using the XSD element's name from the WSDL operation output message part instead of following the previous algorithm as can be seen in org.apache.muse.tools.inspector.ResourceInspector.getOutputName(Operatio n op): private QName getOutputName(Operation op) { Output output = op.getOutput(); if (output == null) return null; Map parts = output.getMessage().getParts(); if (parts.size() != 1) { Object[] filler = { op.getName() }; throw new RuntimeException(_MESSAGES.get("NotDocLiteral", filler)); } Part docLiteralPart = (Part)parts.values().iterator().next(); System.err.println("GETOUTPUTNAME: " + docLiteralPart.getElementName ()); return docLiteralPart.getElementName(); } This makes client proxy implementation fail to understand service's response when the response message's XSD element is not named using the following convention, as in this case ( here the element representing the response message is named "RespouestaServicio"): org.apache.muse.ws.addressing.soap.SoapFault: [ID = 'InvalidProxyResponse'] The output message returned does not match the one expected; the output message expe cted was '{http://test/services/MyService}RespuestaServi cio', but the actual message was '{http://http://test/services/MyService }getArticulosResponse'. at org.apache.muse.core.proxy.ReflectionProxyHandler.fromXML (ReflectionP roxyHandler.java:103) at org.apache.muse.core.AbstractResourceClient.invoke (AbstractResourceCl ient.java:234) at org.apache.muse.core.AbstractResourceClient.invoke (AbstractResourceCl ient.java:211) at net.eusa.tlrsoft.services.TransformationService.TransformationService Proxy.getArticulos(Unknown Source) at prueba.main(prueba.java:17) So, the code always fails when the name of the element that represents the response to a custom operation in Apache Muse doesn't follow the imposed name-convention <operation's name> + "Response". Wouldn't it be easier if Apache Muse uses the same criteria when naming responses on both sides, the server and the client proxy side? Giving the fact that Apache Muse's wsdl2java proxy generation has to be independent of server's code generation, maybe a better approach would be to use information on the WSDL (wich both generators share) to name the response on the server side. This way, the proxy code doesn't depend on naming issues not imposed on the WSDL specification ( I couldn't find anywhere in the specification saying that the XSD element that represents an output message in a WSDL has to have "Response" suffix ). Greets, --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
