commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (COMPRESS-434) Add test case/documentation for specific GzipCompressorInputStream use case
Date Sun, 29 Apr 2018 10:41:00 GMT

     [ https://issues.apache.org/jira/browse/COMPRESS-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Stefan Bodewig resolved COMPRESS-434.
-------------------------------------
       Resolution: Fixed
    Fix Version/s: 1.16

> 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
>             Fix For: 1.16
>
>
> 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-154)
referring to (COMPRESS-146)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message