cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <>
Subject [jira] Assigned: (CXF-2768) Temporary files are not deleted for requests >64kb when using LoggingInInterceptor
Date Wed, 05 May 2010 18:04:03 GMT


Daniel Kulp reassigned CXF-2768:

    Assignee: Daniel Kulp

> Temporary files are not deleted for requests >64kb when using LoggingInInterceptor
> ----------------------------------------------------------------------------------
>                 Key: CXF-2768
>                 URL:
>             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.

View raw message