[
https://issues.apache.org/jira/browse/CXF-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16254812#comment-16254812
]
joel shemtov commented on CXF-7566:
-----------------------------------
It looks like quite a trivial fix. I'm happy to have this assigned to me.
> Misleading Fault message "Could not send message"
> -------------------------------------------------
>
> Key: CXF-7566
> URL: https://issues.apache.org/jira/browse/CXF-7566
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1.14, 3.2.1
> Reporter: joel shemtov
> Priority: Minor
> Labels: newbie
>
> The interceptor class org.apache.cxf.interceptor.MessageSenderInterceptor, on
> its handleMessage() method, adds another interceptor to the interceptor
> chain. The latter is an instance of an inner class. Its handleMessage()
> method closes the conduit. The closing might throw an IOException. If that
> one is caught, it is wrapped in a Fault with the description "Could not send
> Message". The text is taken from a resource bundle.
> There's one problem here: On synchronous sending, IOExceptions may be caught
> here even after a request has been successfully sent. In such case the error
> message "Could not send Message" confuses the user. SocketTimeoutException is
> one such case that I've seen where the server response times out, but the
> user who checks the logs is lead to believe that the request hasn't been sent
> at all. I saw another example in
> https://stackoverflow.com/questions/35961224/javax-xml-ws-webserviceexception-when-invoking-wsdl-service
> where it seems to me that the request has been sent and the response was
> org.apache.cxf.transport.http.HTTPException.
> I'd suggest a more generic description (like "could not conclude message").
> Even no description at all, assuming that the caught exception is properly
> described, would be better than the current situation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
