Dan,
I used tcpmon to snap the response from Mule... It's below.
HTTP/1.1 200 OK
Date: Wed, 17 Jun 2009 03:12:58 EDT
Server: Mule Core/2.2.1
Expires: Wed, 17 Jun 2009 03:12:58 EDT
Pragma: no-cache
Cache-Control: no-cache
MULE_REMOTE_SYNC: true
MULE_REMOTE_CLIENT_ADDRESS: /127.0.0.1:58312
http.context.path: /third-party-services/SilverpopAccount_1_0_0
MULE_ENCODING: UTF-8
MULE_ORIGINATING_ENDPOINT:
endpoint.http.localhost.8449.third.party.services.SilverpopAccount.1.0.0
http.request.path: /third-party-services/SilverpopAccount_1_0_0
Content-Type: text/plain
Content-Length: 0
Keep-Alive: timeout=0
Connection: close
Thanks,
John
dkulp wrote:
>
> On Wed June 17 2009 9:17:57 am jp4 wrote:
>> I am currently using CXF 2.2.2. I have several applications that
>> communicate via web services. The service in question is a one-way
>> service. If I call the service from a CXF client that hits a CXF
>> endpoint
>> the service works properly. If I attempt to route the request through
>> Mule
>> using an HTTP to JMS protocol bridge, I get the following error. I have
>> used SOAPUI to examine the response from Mule as well as from the CXF
>> endpoint. The major difference that I can see is that Mule is setting a
>> Content-Type: text/plain whereas the CXF endpoint omits that header all
>> together. Is the
>> Content-Type header causing the ReadHeadersInterceptor to get invoked?
>> Any
>> help would be greatly appreciated.
>
> Looking at the code, the Content-Type wouldn't do it. However, if mule is
> sending back any content (Content-Length specified, but not 0) or if it's
> "chunked", it would cause this. Can you capture the raw TCP packets for
> the
> response?
>
> Dan
>
>
>>
>> Thanks,
>>
>> John
>>
>> ... 20 more
>> Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
>> at [row,col {unknown-source}]: [1,0]
>> at
>> com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:686)
>> at
>> com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java:2134)
>> at
>> com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:204
>>0) at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
at
>> com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1095)
>> at
>> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessag
>>e(ReadHeadersInterceptor.java:86) at
>> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessag
>>e(ReadHeadersInterceptor.java:57) at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
>>n.java:236) at
>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:645) at
>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRespons
>>eInternal(HTTPConduit.java:2132) at
>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRespons
>>e(HTTPConduit.java:2015) at
>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPCon
>>duit.java:1940) at
>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>> at
>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:627) at
>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInte
>>rceptor.handleMessage(MessageSenderInterceptor.java:62) at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
>>n.java:236) at
>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:471) at
>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:301) at
>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:253) at
>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at
>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:121)
>> ... 29 more
>
> --
> Daniel Kulp
> [email protected]
> http://www.dankulp.com/blog
>
>
--
View this message in context:
http://www.nabble.com/CXF-Client-calling-One-Way-Mule-Service-tp24073484p24080132.html
Sent from the cxf-user mailing list archive at Nabble.com.
