[
https://issues.apache.org/jira/browse/CXF-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp reassigned CXF-2768:
--------------------------------
Assignee: Daniel Kulp
> 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.3, 2.2.5
> Environment: Windows XP, Linux
> Java 1.6
> Reporter: Nathan Waldman
> Assignee: Daniel Kulp
>
> 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?
> {code:title=InputStreamClosingInterceptor}
> 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);
> }
> }
> }
> {code}
> 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.
-
You can reply to this email to add a comment to the issue online.
