You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Nathan Waldman (JIRA)" <ji...@apache.org> on 2010/04/17 00:19:27 UTC
[jira] Updated: (CXF-2768) Temporary files are not deleted for
requests >64kb when using LoggingInInterceptor
[ https://issues.apache.org/jira/browse/CXF-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nathan Waldman updated CXF-2768:
--------------------------------
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 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?
{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.
was:
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.
> 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
>
> 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?
> {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.
-
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