[mule-user] Webservice proxy suddenly gets xop/xml response because of mule headers?

[Andre Hartog]

Hi,

When I call a webservice in SOAPUI, it responds as expected (a soap response). But when I put a Mule webservice proxy in between (simple synchronous http inbound to https outbound service) I get a xop/xml response as some sort of attachment from the webservice (and thus, also from the proxy).

The response starts with:
-----
------=_Part_0_11129126.1273204244731
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml; charset=UTF-8"
Content-Transfer-Encoding: binary
Content-ID: <root.m...@cxf.apache.org>
-----

only then followed by the actual <soap:Envelope>.

I can see in the log4j debug messages that it's the webservice that is generating the xop/xml, but I suspect it is caused by the Mule headers we are sending because a direct call to the webservice with SOAPUI or a generated JAXWS client doesn't return xop/xml.

I suspect that there could be a Mule instance on the webservice end as well, but I'm not sure as it's a webservice from a third party. Could it be that the xop/xml is a result of Mule to Mule communication? Could the http header "X-MULE_REMOTE_SYNC: true" affect the response of the Mule instance on the other end?

Now the interesting thing is that I have two proxy services defined in the same model which connects to the same third party at a different endpoint, and the other one works fine. I suspect that this has something to do with message length, but I'm not sure ...

Is there some way to either prevent the xop response, or to unpack the xop response so it returns the actual content?

Mule config:
-----
<service name="myservice">
<inbound>
<inbound-endpoint address="http://localhost:9080/some/service" synchronous="true">
<no-action-transformer/>
</inbound-endpoint>
</inbound>
<outbound>
<pass-through-router>
<outbound-endpoint address="https://some.server.com/some/other/service" synchronous="true">
<no-action-transformer/>
</outbound-endpoint>
</pass-through-router>
</outbound>
</service>
-----

See the attachment for the anonymised log.

Any help would be appreciated.

Regards,
André

[Andre Hartog]

The underlying problem is that I'm calling the webservice (through the proxy) with a generated JAX WS RI client. It chokes on the mtom message with an WstxUnexpectedCharException:

-----
com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '-' (code 45) in prolog; expected '<'
at [row,col {unknown-source}]: [2,1]
at com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:648)
-----

I've tried enabling mtom on the client:

((SOAPBinding)((BindingProvider)port).getBinding()).setMTOMEnabled(true);

That doesn''t work because it causes the client to send the request in mtom format which, apparently, makes the receiving webservice choke on the same Exception. So somehow they're sending in mtom format when I put my proxy in between, but they can't except mtom themselves.

Still, the interesting question remains, why does the message change at all when I place a mule proxy in between?

André

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


--
You received this message because you are subscribed to the Google Groups "mule-user" group.
To post to this group, send email to mule...@googlegroups.com.
To unsubscribe from this group, send email to mule-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mule-user?hl=en.

[Andre Hartog]

Okay, I think I found the cause. The webservice communicated in MTOM all along, but because the proxy changes the Content-Type

from:

-----
multipart/related; type="application/xop+xml"; boundary="----=_Part_0_22476835.1273214074012"; start="<root.m...@cxf.apache.org>"; start-info="text/xml"
-----

to

-----
text/plain
-----

everything went awry.

The reason I didn't see this immediately is because when the Content-Type is a correct MIME Content-Type for MTOM, SOAPUI hides all MIME stuff from view. This led me to believe there was no MIME/MTOM when calling the webservice directly. It turns out that only when the Content-Type is incorrect, SOAPUI shows the surrounding MIME content, which happened when the Mule proxy was in between. Accordingly, the JAX WS RI client only choked because of an incorrect Content-Type.

I would have expected Mule to keep the original Content-Type in tact. Even setting: contentType="#[header:Content-Type]" on the outbound endpoint doesn't seem to work. Any ideas on how to pass along the correct Content-Type?

[Andre Hartog]

The contentType attribute seems to be used on the way there, but not on the (synchronous) way back. So this config:

-----
<service name="myservice">
<inbound>

<inbound-endpoint address="http://localhost:9080/some/service" contentType="#[header:Content-Type]" synchronous="true">

<no-action-transformer/>
</inbound-endpoint>
</inbound>
<outbound>
<pass-through-router>
<outbound-endpoint address="https://some.server.com/some/other/service" synchronous="true">
<no-action-transformer/>
</outbound-endpoint>
</pass-through-router>
</outbound>
</service>
-----

leads to:

CLIENT -------("text/xml") ------&gt; MULE PROXY -------("text/xml") ------&gt; WEBSERVICE
CLIENT &lt;------("text/plain") ------- MULE PROXY &lt;------("multipart/related") ------- WEBSERVICE

[Andre Hartog]

Fixed it with a response transformer on the outbound endpoint ...

-----
<service name="myservice">
<inbound>

<http:inbound-endpoint address="http://localhost:9080/some/service" synchronous="true">
<no-action-transformer/>
</http:inbound-endpoint>
</inbound>
<outbound>
<pass-through-router>
<https:outbound-endpoint address="https://some.server.com/some/other/service" synchronous="true">
<no-action-transformer/>
<response-transformers>
<message-properties-transformer>
<add-message-property key="Content-type" value="#[header:Content-Type]" />
</message-properties-transformer>
</response-transformers>
</https:outbound-endpoint>
</pass-through-router>
</outbound>
</service>
-----

I would recommend putting this solution in the Mule documentation for creating webservice proxies, since changing the response Content-Type to plain/text really isn't correct for proxying webservices. Also, shouldn't the Content-Type be kept intact by default for the response of an endpoint?

[Andrew Perepelytsya]

Andre,

Could you please file a jira against a Documentation/Website component? You can link back to this thread.

Andrew