You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2019/08/01 00:29:00 UTC
[jira] [Commented] (JCRVLT-349) Do not automatically close input
streams in methods getting it as argument
[ https://issues.apache.org/jira/browse/JCRVLT-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897638#comment-16897638 ]
Tobias Bocanegra commented on JCRVLT-349:
-----------------------------------------
I agree, that it would be better to have a consistent behaviour. I don't agree with 2), as the input stream is always fully consumed (at lest in filevault). a caller would need to create a limiting sub-stream.
I wouldn't change the behaviour as it is right now, but to eliminate inconsistencies within method calls, and update the javadoc.
[~kwin] Do you have a concrete use case where this is a problem?
> Do not automatically close input streams in methods getting it as argument
> --------------------------------------------------------------------------
>
> Key: JCRVLT-349
> URL: https://issues.apache.org/jira/browse/JCRVLT-349
> Project: Jackrabbit FileVault
> Issue Type: Wish
> Components: vlt
> Affects Versions: 3.2.8
> Reporter: Konrad Windszus
> Priority: Major
>
> There are several places in the FileVault code where an input stream is passed as argument to a method and closed within it (even though this is not explicitly mentioned in the javadocs). I think this is bad for the following reasons:
> # it is unexpected for the caller that the given input stream is closed (i.e. this is also never the case for methods taking an input stream in {{org.apache.commons.io.IOUtils}} nor in the JRE itself (https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html#load(java.io.InputStream)))
> # closing the input stream might actually have an undesired effect if the input stream may contain additional input which is supposed to be consumed afterwards
> # closing often happens in a way that there may be leaks in case of exceptions.
> # the behaviour is not documented
> Examples for such behaviour are at
> # https://github.com/apache/jackrabbit-filevault/blob/6df76ba4a45316a84ec1cd10636296d191a82260/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/config/DefaultMetaInf.java#L104
> # https://github.com/apache/jackrabbit-filevault/blob/6df76ba4a45316a84ec1cd10636296d191a82260/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/config/DefaultWorkspaceFilter.java#L364
> If I am not incorrect the behaviour is also not consistent as e.g. in https://github.com/apache/jackrabbit-filevault/blob/6df76ba4a45316a84ec1cd10636296d191a82260/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/config/DefaultMetaInf.java#L136 the input stream is not closed.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)