Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 30 Nov 2016 19:07:59 +0000 (UTC)
From: "Plamen Totev (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.13024542.1480532823000.404243.1480532879829@Atlassian.JIRA>
In-Reply-To: <JIRA.13024542.1480532823000@Atlassian.JIRA>
References: <JIRA.13024542.1480532823000@Atlassian.JIRA> <JIRA.13024542.1480532823373@arcas>
Subject: [jira] [Updated] (COMPRESS-375) Allow the clients of
 ParallelScatterZipCreator to provide ZipArchiveEntryRequestSupplier
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Wed, 30 Nov 2016 19:08:03 -0000


     [ https://issues.apache.org/jira/browse/COMPRESS-375?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Plamen Totev updated COMPRESS-375:
----------------------------------
    Description:=20
Currently clients of {{ParallelScatterZipCreator}} could provide {{ZipArchi=
veEntry}} and {{InputStreamSupplier}} through {{ParallelScatterZipCreator#a=
ddArchiveEntry}}. From those two a {{ZipArchiveEntryRequest}} is created. P=
roviding {{InputStreamSupplier}} solves the problem with opening too many f=
iles - streams are opened just-in-time - when an entry is  compressed, not =
when it's submitted.

But there are use cases when the stream may contain information about the {=
{ZipArchiveEntry}}. In those cases creating {{ZipArchiveEntry}} before the =
{{InputStream}} is opened won't work. If there is an option to supply both =
{{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest}}=
), this will solve the issue.

There is a bug in Plexus Archiver (https://github.com/codehaus-plexus/plexu=
s-archiver/issues/53) that is example for such use case. Plexus Archiver ha=
ve option that allows entries that are already zip files to be stored inste=
ad of compressed ({{AbstractZipArchiver.recompressAddedZips}}). To detect i=
f given entry is zip archive, {{AbstractZipArchiver}} should read the first=
 several bytes of the stream. So creating {{ZipArchiveEntry}} before the st=
ream is opened is not useful - the compress mode is not known. Opening the =
stream when the  {{ZipArchiveEntry}} is created won't work either. Because =
you can add entries to {{ParallelScatterZipCreator}} a lot faster than you =
could compress them you could open too many files very fast. And I don't th=
ink opening and closing the stream is an option as such operations could be=
 relatively expensive in the general case. But if it could supply both the =
{{ZipArchiveEntry}} and the {{InputStream}} just-in-time (by passing {{ZipA=
rchiveEntryRequestSupplier}} to {{ParallelScatterZipCreator}}) then the pro=
blem is solved.

What do you think? Does the addition of {{ParallelScatterZipCreator#addArch=
iveEntry(ZipArchiveEntryRequestSupplier)}} make sense?

  was:
Currently clients of {{ParallelScatterZipCreator}} could provide {{ZipArchi=
veEntry}} and {{InputStreamSupplier}} through {{ParallelScatterZipCreator#a=
ddArchiveEntry}}. From those two a {{ZipArchiveEntryRequest}} is created. P=
roviding {{InputStreamSupplier}} solves the problem with opening too many f=
iles - streams are opened just-in-time - when an entry is  compressed, not =
when it's submitted.

But there are use cases when the stream may contain information about the {=
{ZipArchiveEntry}}. In those cases creating {{ZipArchiveEntry}} before the =
{{InputStream}} is opened won't work. If there is an option to supply both =
{{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest}}=
), this will solve the issue.

There is a bug in Plexus Archiver (https://github.com/codehaus-plexus/plexu=
s-archiver/issues/53) that is example for such use case. Plexus Archiver ha=
ve option that allows entries that are already zip files to be stored inste=
ad of compressed ({{AbstractZipArchiver.recompressAddedZips}}). To detect i=
f given entry is zip archive, {{AbstractZipArchiver}} should read the first=
 several bytes of the stream. So creating {{ZipArchiveEntry}} before the st=
ream is opened is not useful - the compress mode is not known. Opening the =
stream when the  {{ZipArchiveEntry}} is created won't work either. Because =
you can add entries to {{ParallelScatterZipCreator}} a lot faster than you =
could compress them you could open too many files very fast. And I don't th=
ink opening and closing the stream is an option as such operations could be=
 relatively expensive in the general case. But if it could supply both the =
{{ZipArchiveEntry}} and the {{InputStream}} just-in-time (by passing {{ZipA=
rchiveEntryRequestSupplier}} to {{ParallelScatterZipCreator}}) then the pro=
blem is solved.

What do you think. Does the addition of {{ParallelScatterZipCreator#addArch=
iveEntry(ZipArchiveEntryRequestSupplier)}} make sense?


> Allow the clients of ParallelScatterZipCreator to provide ZipArchiveEntry=
RequestSupplier
> -------------------------------------------------------------------------=
---------------
>
>                 Key: COMPRESS-375
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-375
>             Project: Commons Compress
>          Issue Type: Improvement
>          Components: Archivers
>            Reporter: Plamen Totev
>
> Currently clients of {{ParallelScatterZipCreator}} could provide {{ZipArc=
hiveEntry}} and {{InputStreamSupplier}} through {{ParallelScatterZipCreator=
#addArchiveEntry}}. From those two a {{ZipArchiveEntryRequest}} is created.=
 Providing {{InputStreamSupplier}} solves the problem with opening too many=
 files - streams are opened just-in-time - when an entry is  compressed, no=
t when it's submitted.
> But there are use cases when the stream may contain information about the=
 {{ZipArchiveEntry}}. In those cases creating {{ZipArchiveEntry}} before th=
e {{InputStream}} is opened won't work. If there is an option to supply bot=
h {{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest=
}}), this will solve the issue.
> There is a bug in Plexus Archiver (https://github.com/codehaus-plexus/ple=
xus-archiver/issues/53) that is example for such use case. Plexus Archiver =
have option that allows entries that are already zip files to be stored ins=
tead of compressed ({{AbstractZipArchiver.recompressAddedZips}}). To detect=
 if given entry is zip archive, {{AbstractZipArchiver}} should read the fir=
st several bytes of the stream. So creating {{ZipArchiveEntry}} before the =
stream is opened is not useful - the compress mode is not known. Opening th=
e stream when the  {{ZipArchiveEntry}} is created won't work either. Becaus=
e you can add entries to {{ParallelScatterZipCreator}} a lot faster than yo=
u could compress them you could open too many files very fast. And I don't =
think opening and closing the stream is an option as such operations could =
be relatively expensive in the general case. But if it could supply both th=
e {{ZipArchiveEntry}} and the {{InputStream}} just-in-time (by passing {{Zi=
pArchiveEntryRequestSupplier}} to {{ParallelScatterZipCreator}}) then the p=
roblem is solved.
> What do you think? Does the addition of {{ParallelScatterZipCreator#addAr=
chiveEntry(ZipArchiveEntryRequestSupplier)}} make sense?


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)