Mule: Migrating to the New HTTP Connector

Question

I've upgraded from Mule 3.5.x to 3.6.x and since the old http transport is deprecated in 3.6.x I wanted to migrate to the new HTTP connector.

Here is the original code for calling my webservice:

<http:outbound-endpoint ref="OrderEndpoint" doc:name="GetApprovedOrder">
    <cxf:jaxws-client serviceClass="com.acme.orders.IOrderServiceBean"
                port="OrderServiceBean_v2_0Port"
                operation="getApprovedOrderOp" />
</http:outbound-endpoint>

The point I have got to with the new connector is as follows:

<cxf:jaxws-client serviceClass="com.acme.orders.v2_0.IOrderServiceBean" port="OrderServiceBean_v2_0Port" operation="getApprovedOrderOp" />
<http:request config-ref="http.request.config" path="acme-services/OrderServiceBean_v2_0" method="POST" />

The issue that I have is that with the old version of the code, after calling the web service, the payload would be the response [java] object. With the new version of the code the payload is a org.glassfish.grizzly.utils.BufferInputStream containing the soap xml.

I could use a combination of xpath and a jaxb-xml-object-transformer to convert the contents of the stream to the response object, this just seems like a backwards step though.

I have looked into using the jaxws-client without the request and also at the ws-consumer, but my following requirements seems to rule these options out (unless I'm just misunderstanding how to use them).

I need to use the contract first method for calling the web services, see above where I have specified serviceClass rather than wsdl.
The web services use basic auth, therefore I need to specify a username and password.
I need to be able to specify the host and port (or at least the address) of the web service.

I have cross posted this question at forum.mulesoft.org/mulesoft/topics/… — s1mm0t
And your question is whether your implementation is the most optimum ? — Sudarshan
@Sudarshan I want to make a web service call and the payload be the response object, without having to write a whole load of boiler plate code to start parsing and deserializing xml myself. As shown in my example code, this used to be achievable when using the http outbound-endpoint in conjunction with the cxf jaxws-client. — s1mm0t
I agree and with the updated connector you would need to use a object to xml transformer (you mentioned this too) ... so are you asking if this is the only way to do things ? ... basically you have mentioned one possible solution is'nt it — Sudarshan
@Sudarshan the solution of using an object to xml transformer and then parsing and deserializing the object myself seems like a huge step backwards, which is why I was hoping there was a solution similar to the 'old way' of doing things which didn't require all of this additional code. The more code I have to write, the more code I have to maintain and the more likely it is to contain bugs. — s1mm0t

Juan Alberto López Cavallotti Juan Alberto López Cavallotti · Accepted Answer · 2015-06-11T21:02:48

The solution is: wrap your element into a processor-chain

As follows:

<processor-chain>
    <cxf:jaxws-client serviceClass="com.acme.orders.v2_0.IOrderServiceBean" port="OrderServiceBean_v2_0Port" operation="getApprovedOrderOp" />
    <http:request config-ref="http.request.config" path="acme-services/OrderServiceBean_v2_0" method="POST" />
</processor-chain>

This is because cxf is intercepting, so after the processor chain you would have the same object as you had in your previous solution.

Mule: Migrating to the New HTTP Connector

1 Answers