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