[
https://issues.apache.org/jira/browse/COMPRESS-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342540#comment-16342540
]
Stefan Bodewig commented on COMPRESS-434:
-----------------------------------------
There is a test for the false case:
[https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=blob;f=src/test/java/org/apache/commons/compress/compressors/GZipTestCase.java;h=02fda3e2d9af5fc91a2993910654852c6d5ee6b0;hb=HEAD#l77]
- one might miss it when grepping for the constructor as it uses an
indirection via {{CompressorStreamFactory}}.
As for your second suggestion, does
[https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=blobdiff;f=src/main/java/org/apache/commons/compress/compressors/gzip/GzipCompressorInputStream.java;h=a4064994d066c253622d379b1d99380a9b4d0ce9;hp=bbf40ee1ab293cd77bdb330ed7942431068447dd;hb=04f887002eb2c99ef3e86f2c967df91e2d4dfdfe;hpb=237b7e3d8b0bcccc4962a7ef6d163b8bed2a5e1b]
look better?
We haven't formally verified we are compatible with RFC 1952 so I'm a bit
reluctant claiming that we are. But of course the RFC is the very definition of
GZIP so this is what we strive to be compatible with.
> 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-154) referring to (COMPRESS-146)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
