Temporary files are not deleted for requests >64kb when using
LoggingInInterceptor
----------------------------------------------------------------------------------
Key: CXF-2768
URL: https://issues.apache.org/jira/browse/CXF-2768
Project: CXF
Issue Type: Bug
Components: Core
Affects Versions: 2.2.5, 2.2.3
Environment: Windows XP, Linux
Java 1.6
Reporter: Nathan Waldman
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 is
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
