[
https://issues.apache.org/jira/browse/COMPRESS-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Thulin updated COMPRESS-434:
-----------------------------------
Description:
The constructor for GzipCompressedInputStream() allows two forms of creation:
one with the decompressConcatenated parameter true, and one with it false.
The second case (false) does not have any accompanying test case. The only
testcase present is testConcatenatedStreamsReadFully, which uses
decompressConcatenated = true.
*Suggestion 1: Provide a test case for the decompressConcatenated = false use
case to test that separate gzip members are extracted from the same
InputStream. Existing test data ('multiple.gz') might be used for this. (I'm
assuming RFC1952 compliance here ... see below)
The lack of code indirectly strikes against practical use of this form of
constructor: it is not at all obvious from the JavaDoc how concatenated
archives are extracted while retaining their independent identity.
* Suggestion 2: Add sample code for this usecase to JavaDoc.
* Suggestion 3: If GzipCompressedInputStream is intended to provide support for
RFC1952-compatible streams, please document it. Alternatively, document that
it isn't.
Added: I see now that the lack of testcase and doc has been identified earlier
(COMPRESS-146)
was:
The constructor for GzipCompressedInputStream() allows two forms of creation:
one with the decompressConcatenated parameter true, and one with it false.
The second case (false) does not have any accompanying test case. The only
testcase present is testConcatenatedStreamsReadFully, which uses
decompressConcatenated = true.
*Suggestion 1: Provide a test case for the decompressConcatenated = false use
case to test that separate gzip members are extracted from the same
InputStream. Existing test data ('multiple.gz') might be used for this. (I'm
assuming RFC1952 compliance here ... see below)
The lack of code indirectly strikes against practical use of this form of
constructor: it is not at all obvious from the JavaDoc how concatenated
archives are extracted while retaining their independent identity.
* Suggestion 2: Add sample code for this usecase to JavaDoc.
* Suggestion 3: If GzipCompressedInputStream is intended to provide support for
RFC1952-compatible streams, please document it. Alternatively, document that
it isn't.
> Add test case/documentation for specific GzipCompressorInputStream use case
> ---------------------------------------------------------------------------
>
> Key: COMPRESS-434
> URL: https://issues.apache.org/jira/browse/COMPRESS-434
> Project: Commons Compress
> Issue Type: Improvement
> Components: Compressors
> Environment: Only observed this for Compress 1.15; have not checked
> earlier versions.
> Reporter: Anders Thulin
> Priority: Minor
>
> The constructor for GzipCompressedInputStream() allows two forms of creation:
> one with the decompressConcatenated parameter true, and one with it false.
> The second case (false) does not have any accompanying test case. The only
> testcase present is testConcatenatedStreamsReadFully, which uses
> decompressConcatenated = true.
> *Suggestion 1: Provide a test case for the decompressConcatenated = false
> use case to test that separate gzip members are extracted from the same
> InputStream. Existing test data ('multiple.gz') might be used for this.
> (I'm assuming RFC1952 compliance here ... see below)
> The lack of code indirectly strikes against practical use of this form of
> constructor: it is not at all obvious from the JavaDoc how concatenated
> archives are extracted while retaining their independent identity.
> * Suggestion 2: Add sample code for this usecase to JavaDoc.
> * Suggestion 3: If GzipCompressedInputStream is intended to provide support
> for RFC1952-compatible streams, please document it. Alternatively, document
> that it isn't.
> Added: I see now that the lack of testcase and doc has been identified
> earlier (COMPRESS-146)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
