[jira] [Resolved] (COMPRESS-208) Add support for ZIP archives with PK00PK signature
[
https://issues.apache.org/jira/browse/COMPRESS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-208.
-
Resolution: Fixed
Fix Version/s: 1.5
of course I also had to modify the offsets inside the central directory and the
end of central directory record.
Added support for PK00 archives with svn revision 1427363
Add support for ZIP archives with PK00PK signature
--
Key: COMPRESS-208
URL: https://issues.apache.org/jira/browse/COMPRESS-208
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.4.1
Reporter: Dmitry Katsubo
Fix For: 1.5
Attachments: EP02797238.zip
ZIP archive with PK00PK signature is not recognized as ZIP archive by
{{ArchiveStreamFactory.createArchiveInputStream()}}. Header hexdump:
{code}
00: 50 4B 30 30 50 4B 03 04 │ 14 00 00 00 08 00 48 7D PK00PK♥♦¶ ◘
H}
10: F4 36 04 E0 50 2C 04 27 │ 01 00 E2 3F 10 00 37 00 Ї6♦рP,♦'☺ т?► 7
20: 00 00 4E 39 32 30 34 35 │ 20 53 45 52 20 4A 52 4EN92045 SER
JRN
30: 20 72 65 76 69 73 65 64 │ 20 73 65 71 20 6C 69 73 revised seq
lis
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONFIGURATION-519) Provide a builder API for creating configuration objects
Oliver Heger created CONFIGURATION-519:
--
Summary: Provide a builder API for creating configuration objects
Key: CONFIGURATION-519
URL: https://issues.apache.org/jira/browse/CONFIGURATION-519
Project: Commons Configuration
Issue Type: Improvement
Affects Versions: 1.9
Reporter: Oliver Heger
Fix For: 2.0
Currently, concrete {{Configuration}} implementations are directly instantiated
using their constructors. How this works in detail depends on a concrete class:
some constructors accept initializazion parameters, in other cases only a
default constructor is available, and further properties have to be set using
set methods.
File-based configurations allow a client to pass in the file to be loaded in
various forms (URL, File, file name, etc.). The data is then directly loaded by
the constructor which is problematic for various reasons:
* The constructors execute complex operations.
* Loading of the configuration file can fail which will then throw an exception.
* The constructors invoke non-final methods for loading data. (_Note_: This is
not only a theoretical problem but has indeed caused trouble in practice, e.g.
when trying to set a default encoding for {{PropertiesConfiguration}}.)
* Some properties only take effect when set before loading a configuration
file. So when these properties are needed, it is not possible to use a
constructor which already performs the load operation. This API is confusing.
As an alternative, a builder-like API can be provided: Client code creates a
builder object and sets initialization properties for the {{Configuration}}
object to be constructed using a convenient (fluent) API. Then a fully
initialized {{Configuration}} object can be obtained from the builder. The
required steps for creating a configuration would be always the same, no matter
which concrete {{Configuration}} subclass is actually created.
In addition, builders could play an important role when it comes to improving
the current reloading mechanisms. For this a separate ticket will be opened.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONFIGURATION-520) Rework reloading mechanisms
Oliver Heger created CONFIGURATION-520:
--
Summary: Rework reloading mechanisms
Key: CONFIGURATION-520
URL: https://issues.apache.org/jira/browse/CONFIGURATION-520
Project: Commons Configuration
Issue Type: Improvement
Components: File reloading
Affects Versions: 1.9
Reporter: Oliver Heger
Fix For: 2.0
The current implementation of reloading features is tightly coupled to
file-based configurations: On each property access a reloading strategy is
queried; if it indicates that a reload is required, the content of the
configuration is replaced by the file on hard disc.
The advantage of this approach is that it is very transparent for client code;
no specific actions have to be taken to enable reloading. However, there are
also many problems:
* There is no control over reloading. It can happen at any time. This could
cause problems if a configuration contains multiple related properties, and a
reload happens while an application reads them: properties read before the
reload may not be compatible with values read afterwards.
* There is no sound error handling. A failed reload operation corrupts the
configuration (see CONFIGURATION-136).
* There is no support for other reloading triggers (e.g. periodic checks) or
event notifications when the change of a configuration source is detected.
* The implementation of reloading features is spread over a bunch of methods in
{{AbstractFileConfiguration}}; each affected method contains a reload check.
* It is very hard (or even impossible) to provide an efficient thread-safe
implementation of configurations; there has to be synchronization with
reloading operations.
* The mechanisms available are specific to file-based configurations, there is
no generic approach.
The disadvantages listed above can be addressed by moving reloading
functionality from specific {{Configuration}} implementations to builder
objects responsible for the creation of configurations (see CONFIGURATION-519).
This would require client code to deal with reloading in a slightly different
(and probably slightly less transparent) way, but it would simplify the current
implementation and enable advanced reloading features.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-201) No constructor to create a TarArchiveEntry link with leading slash
[
https://issues.apache.org/jira/browse/COMPRESS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-201.
-
Resolution: Fixed
Fix Version/s: 1.5
added new constructor with svn revision 1427488
No constructor to create a TarArchiveEntry link with leading slash
--
Key: COMPRESS-201
URL: https://issues.apache.org/jira/browse/COMPRESS-201
Project: Commons Compress
Issue Type: Bug
Components: Compressors
Affects Versions: 1.4.1
Reporter: Thomas Mortagne
Priority: Minor
Labels: link, tar
Fix For: 1.5
I want to create a link with a leading slash and put it in a tar archive
(Debian package).
The following constructors are provided
{code}
public TarArchiveEntry(String name, boolean preserveLeadingSlashes)
public TarArchiveEntry(String name, byte linkFlag)
{code}
but there is no
{code}
public TarArchiveEntry(String name, byte linkFlag, boolean
preserveLeadingSlashes)
{code}
so I have to overwrite the name using setName(String) which is not very clean.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-168) getName of ZipArchiveEntry
[ https://issues.apache.org/jira/browse/COMPRESS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-168. - Resolution: Not A Problem use one of the existing ways to specify the encoding explicitly getName of ZipArchiveEntry -- Key: COMPRESS-168 URL: https://issues.apache.org/jira/browse/COMPRESS-168 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.2 Environment: J2EE Environment with jdk 1.4 Reporter: Pavithra Kumar Attachments: TestZip.zip getName method of ZipArchiveEntry is not giving arabic file names. Instead of that it gives some chunked characters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-159) ChangeSetPerformer not reliable for ZipArchiveInputStreams
[
https://issues.apache.org/jira/browse/COMPRESS-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-159.
-
Resolution: Fixed
Fix Version/s: 1.5
added a new perform overload with svn revision 1427509
ChangeSetPerformer not reliable for ZipArchiveInputStreams
--
Key: COMPRESS-159
URL: https://issues.apache.org/jira/browse/COMPRESS-159
Project: Commons Compress
Issue Type: Bug
Components: Changesets
Affects Versions: 1.2
Environment: OpenJDK Runtime Environment (IcedTea6 1.8.7)
(6b18-1.8.7-4)
OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode)
Linux 2.6.38-1-amd64 #1 SMP Wed Mar 16 17:38:02 UTC 2011 x86_64 GNU/Linux
Reporter: Jon Michaelchuck
Fix For: 1.5
ChangeSetPerformer's perform function takes an ArchiveInputStream as an
argument and thus frequently runs into issues described under heading
'ZipArchiveInputStream vs ZipFile' at
http://commons.apache.org/compress/zip.html
Personally for a simple local solution I've added a slightly modified
performZip function taking a ZipFile argument in place of the
ArchiveInputStream argument:
diff perform performZip
1c1
public ChangeSetResults perform(ArchiveInputStream in,
ArchiveOutputStream out)
---
public ChangeSetResults performZip(ZipFile zf, ArchiveOutputStream out)
17,18c17,18
ArchiveEntry entry = null;
while ((entry = in.getNextEntry()) != null) {
---
ArrayListZipArchiveEntry entries =
Collections.list(zf.getEntriesInPhysicalOrder());
for (ZipArchiveEntry entry : entries) {
46c46
copyStream(in, out, entry);
---
copyStream(zf.getInputStream(entry), out, entry);
A permanent fix may require some re-design, the perform(ArchiveInputStream
in, ArchiveOutputStream out) abstraction may be overly general.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
