[mule-user] Mule 3.2 cxf:jaxws-client - error during WS response

[Vitaliy Orbidan]

It looks like cxf is chocking on the special non-UTF-8 characters coming back from the WS, but I think that those characters are introduced by ReleasingInputStream, and are not a part of the response SOAP message. The same request with all the same parameters, executed from SOAP UI comes back just fine.
The interesting part is that even though there is an error, which can be caught with default exception processing, the message from SOAP WS gets delivered to the next component in the flow, in addition to being processed by the default-exception-strategy.
Has any seen this? is there a solution or workaround?
[code]
2012-01-05 19:25:04,424 [[cemp-1.0-SNAPSHOT].cemp-poll-ws-request.stage1.02] WARN org.apache.cxf.phase.PhaseInterceptorChain - Interceptor for {http://xml.comcast.com/usage/services}UsageService#{http://xml.comcast.com/usage/services}getUserActivity has thrown exception, unwinding now
java.lang.RuntimeException: Couldn't parse stream.
at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1099)
at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:104)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:755)
at org.mule.module.cxf.transport.MuleUniversalConduit.dispatchMuleMessage(MuleUniversalConduit.java:279)
at org.mule.module.cxf.transport.MuleUniversalConduit$2.handleMessage(MuleUniversalConduit.java:193)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
at $Proxy46.getUserActivity(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mule.module.cxf.CxfOutboundMessageProcessor.doSendWithProxy(CxfOutboundMessageProcessor.java:174)
at org.mule.module.cxf.CxfOutboundMessageProcessor.process(CxfOutboundMessageProcessor.java:129)
at org.mule.processor.chain.DefaultMessageProcessorChain.doProcess(DefaultMessageProcessorChain.java:99)
at org.mule.processor.chain.AbstractMessageProcessorChain.process(AbstractMessageProcessorChain.java:64)
at org.mule.processor.AbstractInterceptingMessageProcessorBase.processNext(AbstractInterceptingMessageProcessorBase.java:105)
at org.mule.interceptor.AbstractEnvelopeInterceptor.process(AbstractEnvelopeInterceptor.java:55)
at org.mule.processor.AsyncInterceptingMessageProcessor.processNextTimed(AsyncInterceptingMessageProcessor.java:111)
at org.mule.processor.SedaStageInterceptingMessageProcessor$SedaStageWorker.doWork(SedaStageInterceptingMessageProcessor.java:200)
at org.mule.processor.SedaStageInterceptingMessageProcessor$SedaStageWorker.doRun(SedaStageInterceptingMessageProcessor.java:180)
at org.mule.work.AbstractMuleEventWork.run(AbstractMuleEventWork.java:43)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0xac (at char #1, byte #-1)
at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:536)
at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:585)
at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:610)
at com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:316)
at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1097)
... 30 more
Caused by: java.io.CharConversionException: Invalid UTF-8 start byte 0xac (at char #1, byte #-1)
at com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:303)
at com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:397)
at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
at com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
at com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:531)
... 34 more
2012-01-05 19:25:04,426 [[cemp-1.0-SNAPSHOT].cemp-poll-ws-request.stage1.02] ERROR org.mule.exception.DefaultMessagingExceptionStrategy -
********************************************************************************
Message : null (java.lang.reflect.InvocationTargetException)
Code : MULE_ERROR-10999
--------------------------------------------------------------------------------
Exception stack is:
1. Invalid UTF-8 start byte 0xac (at char #1, byte #-1) (java.io.CharConversionException)
com.ctc.wstx.io.UTF8Reader:303 (null)
2. Invalid UTF-8 start byte 0xac (at char #1, byte #-1) (com.ctc.wstx.exc.WstxIOException)
com.ctc.wstx.stax.WstxInputFactory:536 (null)
3. Couldn't parse stream. (java.lang.RuntimeException)
org.apache.cxf.staxutils.StaxUtils:1099 (null)
4. Couldn't parse stream. (javax.xml.ws.soap.SOAPFaultException)
org.apache.cxf.jaxws.JaxWsClientProxy:146 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/xml/ws/soap/SOAPFaultException.html)
5. null (java.lang.reflect.InvocationTargetException) (org.mule.api.DefaultMuleException)
org.mule.module.cxf.CxfOutboundMessageProcessor:139 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/DefaultMuleException.html)
--------------------------------------------------------------------------------
Root Exception stack trace:
java.io.CharConversionException: Invalid UTF-8 start byte 0xac (at char #1, byte #-1)
at com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:303)
at com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:397)
at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
+ 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything)
********************************************************************************
[/code]

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

http://xircles.codehaus.org/manage_email

[Vitaliy Orbidan]

Well,
It turns out that the Mule's documentation at [http://www.mulesoft.org/documentation/display/MULE3USER/Consuming+Web+Services+with+CXF] totally sucks, which unfortunately is not surprising anymore.

In order for the call to WS with jaxws-client to return a JAXB response you have to put <cxf:jaxws-client/> INSIDE of the <http:outbound-endpoint/>. Thanks to rvo...@gmail.com and his post at [http://mule.1045714.n5.nabble.com/Process-jaxws-client-response-as-JAXB-object-td4808356.html]

Now, the other issue is that all message headers are lost, event the invocation scoped once, which are supposed to be preserved withing a flow according to Mule's documentation, but on the other hand Mule's documentation ranks very low as source of truth in my eyes.

[Evangelina Martinez]

Hi,

First of all, can you send us the configuration that is failing and also telling me which version of Mule you are using?

About the first error that you had, jaxws-client should work either inside the http outbound endpoint or before it. Placing it after the endpoint would cause an error like the one you were having. I couldn't reproduce your error placing it before the outbound endpoint, so if you send us the configuration it will be helpful to find the problem.

 As for your second issue, there is a known problem with the invocation properties that is being fixed for Mule 3.3, they are lost after the outbound endpoint, if you use session properties for example, that won't happen.

HTH
Eva

[Vitaliy Orbidan]

Attached are Eclipse projects for both the Server and client.

Client test case is of interest. See my comments in mule-config.xml

Thank you,

Vitaliy

[Vitaliy Orbidan]

I have actually reproduced the error I was getting.
Please see the attached Eclipse mavenized projects.

Here is what contributed to this erroneous configuration:
1. Example at [http://www.mulesoft.org/documentation/display/MULE3USER/Consuming+Web+Services+with+CXF] implies that it is OK to transform ReleasingInputStream with a set of transformers after the <http:outbound-endpoint/>
2. Since the expected payload is an XML, and it contains repeating groups, it is natural to try and split it with xpath splitter
3. The result of the xpath splitter is a DOM object

I believe after this it is impossible to pass the InputStream back to jaxws-client, and that is why it fails with the following exception:

java.lang.RuntimeException: Couldn't parse stream.
at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1099)
at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:104)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:755)
at org.mule.module.cxf.transport.MuleUniversalConduit.dispatchMuleMessage(MuleUniversalConduit.java:279)
at org.mule.module.cxf.transport.MuleUniversalConduit$2.handleMessage(MuleUniversalConduit.java:193)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)

at $Proxy47.findProductsByExample(Unknown Source)

[Evangelina Martinez]

Hi,

Thanks for sending the projects, I've been able to reproduce your issue. As you reported the behavior of the cxf jaxws client is different whether you place it inside the outbound endpoint or outside.

In the first case after the outbound endpoint your are going to have the response from the service, in this case the payload type will be ArrayOfProduct. And the transformers that you configure afterwards will be applied on this payload.

In the second scenario, the one that is failing you, the transformers after the outbound endpoint are going to be applied before sending it again to CXF to obtain the final result. What you are sending to CXF in this case is an Array List of xml strings, representing each product. CXF can't convert this String to an XML document and therefore fails.

I believe the behavior that you want is the first one, having the CXF message processor as child to the outbound, and the other case is a bug, they should behave the same way.I will need to confirm this, and if it is I'll open a bug to fix it.

Eva