[
https://issues.apache.org/jira/browse/CXF-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
joel shemtov updated CXF-7566:
------------------------------
Affects Version/s: (was: 3.0.15)
> 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)
