You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by "Florian Müller (JIRA)" <ji...@apache.org> on 2017/03/12 17:33:04 UTC

[jira] [Commented] (CMIS-1019) AbstractBrowserServiceCall impls do not close create content streans.

    [ https://issues.apache.org/jira/browse/CMIS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15906600#comment-15906600 ] 

Florian Müller commented on CMIS-1019:
--------------------------------------

The streams are actually created in CmisBrowserBindingServlet (-> POSTHttpServletRequestWrapper) and they are closed there as well. The temp files should be deleted in any case.
Closing the streams earlier is not necessary, but doesn't hurt. We could remove that code from the InMemory and the FileShare repositories.
I don't see a reason to change subclasses of AbstractBrowserServiceCall.

(Please note, that deleting temp files on Windows fails sometimes. In most of these cases, someone still has a handle on that file.)

> AbstractBrowserServiceCall impls do not close create content streans.
> ---------------------------------------------------------------------
>
>                 Key: CMIS-1019
>                 URL: https://issues.apache.org/jira/browse/CMIS-1019
>             Project: Chemistry
>          Issue Type: Improvement
>          Components: opencmis-server
>    Affects Versions: OpenCMIS 1.0.0
>            Reporter: MIURA Toru
>
> AbstractBrowserServiceCall  implementations such as CraeteDocument, 
> SetContentStream  and AppendContentStream do not close content streams
> created in serve() methods by using AbstractBrowserServiceCall#createContentStream().
> If the implementation of SPI's ObjectService#createDocument, 
> setContentStream or appendContentStream does not close the content stream, 
> resources such as temporary files created by ThresholdOutputStream remain.
> Whereas the inmemory and fileshare repositories close the content streams provided,
> I believe the creator of streams should take responsibility to close it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)