Details
Major Description
When we use the LoggingInInterceptor and receive a request that is larger than 64kb, CXF creates a temporary file, but does not delete it.
The LoggingInInterceptor closes the message's original input stream and opens a new one. In the case of a request that is larger than 64kb, the CachedOutputStream creates a temporary file which the new input stream reads. The new FileInputStream's close method is overridden to delete the temporary file when it is closed, but that close is never called.
It appears that CXF assumes that the input stream passed to the interceptors does not need to be closed explicitly, because in the normal case that input stream is the HttpServletRequest input stream which will be closed by the container. However when LoggingInInterceptor passes along a new input stream to the rest of the interceptor chain, it is left unclosed.
I created a new InputStreamClosingInterceptor that explicitly closes the input stream if it exists and set it for the PRE_INVOKE phase so that it runs after all other interceptors are done with the input stream. With this change the new input stream is successfully closed and the temporary file is correctly deleted. Is this safe?
public class InputStreamClosingInterceptor extends AbstractPhaseInterceptor<Message> { public InputStreamClosingInterceptor() { super(Phase.PRE_INVOKE); } public void handleMessage(Message message) throws Fault { InputStream inputStream = message.getContent(InputStream.class); if(inputStream != null) { closeInputStream(inputStream); } } private void closeInputStream(InputStream inputStream) { try { inputStream.close(); } catch (IOException e) { throw new Fault(e); } } }
A more elegant solution would be to modify CXF so that it does not assume that the input stream passed to the interceptor chain is the same stream at the end of the chain, and that it explicitly closes the resultant stream at the end of the chain processing in the framework.