[
https://issues.apache.org/jira/browse/COMPRESS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Plamen Totev updated COMPRESS-375:
----------------------------------
Description:
Currently clients of {{ParallelScatterZipCreator}} could provide
{{ZipArchiveEntry}} 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, 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/plexus-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 instead of compressed
({{AbstractZipArchiver.recompressAddedZips}}). To detect if given entry is zip
archive, {{AbstractZipArchiver}} should read the first several bytes of the
stream. So creating {{ZipArchiveEntry}} before the stream 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 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 the {{ZipArchiveEntry}} and the
{{InputStream}} just-in-time (by passing {{ZipArchiveEntryRequestSupplier}} to
{{ParallelScatterZipCreator}}) then the problem is solved.
What do you think? Does the addition of
{{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}}
makes sense?
was:
Currently clients of {{ParallelScatterZipCreator}} could provide
{{ZipArchiveEntry}} 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, 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/plexus-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 instead of compressed
({{AbstractZipArchiver.recompressAddedZips}}). To detect if given entry is zip
archive, {{AbstractZipArchiver}} should read the first several bytes of the
stream. So creating {{ZipArchiveEntry}} before the stream 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 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 the {{ZipArchiveEntry}} and the
{{InputStream}} just-in-time (by passing {{ZipArchiveEntryRequestSupplier}} to
{{ParallelScatterZipCreator}}) then the problem is solved.
What do you think? Does the addition of
{{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}}
make sense?
> Allow the clients of ParallelScatterZipCreator to provide
> ZipArchiveEntryRequestSupplier
> ----------------------------------------------------------------------------------------
>
> 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
> {{ZipArchiveEntry}} 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, 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/plexus-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 instead of compressed
> ({{AbstractZipArchiver.recompressAddedZips}}). To detect if given entry is
> zip archive, {{AbstractZipArchiver}} should read the first several bytes of
> the stream. So creating {{ZipArchiveEntry}} before the stream 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 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 the
> {{ZipArchiveEntry}} and the {{InputStream}} just-in-time (by passing
> {{ZipArchiveEntryRequestSupplier}} to {{ParallelScatterZipCreator}}) then the
> problem is solved.
> What do you think? Does the addition of
> {{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}}
> makes sense?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
