[ANNOUNCE] Apache Jackrabbit Oak 1.0.40 released
The Apache Jackrabbit community is pleased to announce the release of Apache Jackrabbit Oak 1.0.40. The release is available for download at: http://jackrabbit.apache.org/downloads.html See the full release notes below for details about this release: Release Notes -- Apache Jackrabbit Oak -- Version 1.0.40 Introduction Jackrabbit Oak is a scalable, high-performance hierarchical content repository designed for use as the foundation of modern world-class web sites and other demanding content applications. Apache Jackrabbit Oak 1.0.40 is a patch release that contains fixes and improvements over Oak 1.0. Jackrabbit Oak 1.0.x releases are considered stable and targeted for production use. The Oak effort is a part of the Apache Jackrabbit project. Apache Jackrabbit is a project of the Apache Software Foundation. Changes in Oak 1.0.40 - Sub-task [OAK-5299] - Introduce BlobFactory in OakDirectory Technical task [OAK-6237] - Tomcat JDBC pool's StatementCache interceptor may cache borked PreparedStatements with DB2 [OAK-6652] - RDB*Store: update postgresql JDBC driver reference to 42.1.4 [OAK-6660] - RDB*Store: update mysql JDBC driver reference to 5.1.44 (2017-08-30) [OAK-6696] - RDB*Store: update Tomcat JDBC pool dependency to 7.0.81 [OAK-6782] - RDBDocumentStore: inconsistent handling of cache invalidation on remove() [OAK-6903] - RDB*Store: update Tomcat JDBC pool dependency to 7.0.82 [OAK-7068] - RDBBlobStore may wrap SQLExceptions into RuntimeExceptions [OAK-7069] - RDBDataSourceWrapper: properly name setTemporaryUpdateException Bug [OAK-4518] - ConcurrentAddReferenceTest fails occasionally [OAK-5238] - IndexCopier causes concurrent update on NodeBuilder [OAK-5933] - Checkpoints are not sorted correctly in RepositorySidegrade [OAK-6011] - Test failure: JdbcToSegmentTest:validateMigration [OAK-6057] - incorrect system property check in blob/upgrade tests [OAK-6306] - upgrade uses lucene wrong version (transient dependency) [OAK-6360] - Failed to retrieve previously indexed checkpoint in composite node store [OAK-6454] - Inaccurate data in the oak-upgrade progress logger [OAK-6560] - Sidegrade uses too much memory [OAK-6611] - [upgrade][oak-blob-cloud] Many S3DataStore errors during migration with oak-upgrade [OAK-6633] - Overwriting a versionable node with the copy-versions=false doesn't remove versionable properties [OAK-6685] - Background operation may fail when document is malformed [OAK-6953] - CacheLIRS cannot be disabled [OAK-6970] - IncludeIndexTest failure [OAK-7101] - Stale documents in RDBDocumentStore cache Improvement [OAK-2638] - Use message from causing exception in DocumentStoreException.convert() [OAK-4863] - Reduce query batch size for deleted documents [OAK-5317] - MongoBlobStore creates _id index unnecessarily [OAK-6003] - Allow to migrate checkpoints for all type of sidegrades [OAK-6131] - No need to rebuild the counter/uuid index anymore [OAK-6188] - Allow to exclude nodes containing name fragment during the migration [OAK-6190] - Allow to migrate checkpoints even if the custom include paths are specified [OAK-6218] - Including id in DocumentStoreException which wrap MongoException [OAK-6650] - new release checksum requirements [OAK-6878] - Populate S3DataStore fields with the passed properties in oak-upgrade Task [OAK-6655] - Update travis build configuration [OAK-6657] - Remove travis webhook configuration [OAK-6701] - Update Oak 1.0 to Jackrabbit 2.8.6 [OAK-6952] - add SHA512 checksums to releases [OAK-6971] - Remove composite node store-related features from the oak-upgrade [OAK-7076] - Update Oak 1.0 to Jackrabbit 2.8.7 In addition to the above-mentioned changes, this release contains all changes included in previous Apache Jackrabbit Oak 1.0.x releases. Please note, the backported RDB support for the DocumentNodeStore is considered experimental at this point and is not yet ready for production use. Feel free to try it out and report any issues you may see to the Oak developers. For more detailed information about all the changes in this and other Oak releases, please see the Oak issue tracker at https://issues.apache.org/jira/browse/OAK Release Contents This release consists of a single source archive packaged as a zip file. The archive can be unpacked with the jar tool from your JDK installation. See the README.md file for instructions on how to build this release. The source archive is accompanied by SHA1 and MD5 checksums and a PGP signature that you can use to verify the authenticity of your download. The public key used for the PGP signature can be found at http://www.apache.org/dist/jackrabbit/KEYS. About Apache Jackrabbit Oak --- Jackrabbit Oak is a scalable, high-performance hierarchical content repository d
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315859#comment-16315859
]
Dirk Rudolph commented on JCRVLT-257:
-
I created a unit test here
https://github.com/Buuhuu/jackrabbit-filevault/commit/ddf685b4f8ba930ecfc77286eeb1f49a4f2be25a
failing with
{code}
Caused by: java.util.zip.ZipException: invalid block type
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
at
org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
at
org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
at
org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
at
org.apache.jackrabbit.vault.fs.io.JarExporterTest.testEntriesWithSuppressedCompression(JarExporterTest.java:63)
{code}
Not the same exception as in the description but thrown at the same place due
to DataFormatException thrown by native code.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel
> Version 17.3.0: Thu Nov 9 18:09:22 PST 2017;
> root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCRVLT-258) Default compression level incorrectly set to NO_COMPRESSION (0)
[
https://issues.apache.org/jira/browse/JCRVLT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-258:
---
Description:
Default compression level has been changed in this commit from
{{Deflater#DEFAULT_COMPRESSION}} (-1) to {{DEFLATER#NO_COMPRESSION}} (0):
https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
The original patch from JCRVLT-163 contained -1 (which was IMHO correct and is
also more in line on how packages have been created prior to JCRVLT-163).
was:
Default compression level has been changed in this commit from -1
(Deflater#DEFAULT_COMPRESSION) to DEFLATER#NO_COMPRESSION (0):
https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
The original patch from JCRVLT-163 contained -1 (which was IMHO correct and is
also more in line on how packages have been created prior to JCRVLT-163).
> Default compression level incorrectly set to NO_COMPRESSION (0)
> ---
>
> Key: JCRVLT-258
> URL: https://issues.apache.org/jira/browse/JCRVLT-258
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40
>Reporter: Konrad Windszus
>
> Default compression level has been changed in this commit from
> {{Deflater#DEFAULT_COMPRESSION}} (-1) to {{DEFLATER#NO_COMPRESSION}} (0):
> https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
> The original patch from JCRVLT-163 contained -1 (which was IMHO correct and
> is also more in line on how packages have been created prior to JCRVLT-163).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315875#comment-16315875
]
Konrad Windszus edited comment on JCRVLT-257 at 1/8/18 8:40 AM:
The default being {{NO_COMPRESSION}} (0) is most probably a mistake. This is
tracked in JCRVLT-258.
was (Author: kwin):
The default being `NO_COMPRESSION` is most probably a mistake. This is tracked
in JCRVLT-258.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel
> Version 17.3.0: Thu Nov 9 18:09:22 PST 2017;
> root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315875#comment-16315875
]
Konrad Windszus commented on JCRVLT-257:
The default being `NO_COMPRESSION` is most probably a mistake. This is tracked
in JCRVLT-258.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel
> Version 17.3.0: Thu Nov 9 18:09:22 PST 2017;
> root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315886#comment-16315886
]
Timothee Maret edited comment on JCRVLT-257 at 1/8/18 8:51 AM:
---
Ok.. just noticed (JCRVLT-258) opened by [~kwin] (our comments crossed).
So, The default for CRX Package Manager should not be {{NO_COMPRESSION}} IMO.
The default for CRX Package Manager should be reverted back to
{{DEFAULT_COMPRESSION}}. Indeed, using {{NO_COMPRESSION}} CRX Package Manager
has impact on the size (size increase) of the packages created down the line in
AEM and other consumers, which is IMO not something we want.
Sling SCD will still use {{BEST_SPEED}} as default, which is what we need.
[~diru] could you confirm whether the ZipException exception is thrown with
{{DEFAULT_COMPRESSION}} ?
was (Author: marett):
Ok.. just noticed (JCRVLT-258) opened by [~kwin] (our comments crossed).
So, The default for CRX Package Manager should not be no compression IMO, and
be reverted back to {{DEFAULT_COMPRESSION}}. Indeed, using {{NO_COMPRESSION}}
CRX Package Manager has impact on the size (size increase) of the packages
created down the line in AEM and other consumers, which is IMO not something we
want.
Sling SCD will still use {{BEST_SPEED}} as default, which is what we need.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel
> Version 17.3.0: Thu Nov 9 18:09:22 PST 2017;
> root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JCRVLT-258) Default compression level incorrectly set to NO_COMPRESSION (0)
Konrad Windszus created JCRVLT-258: -- Summary: Default compression level incorrectly set to NO_COMPRESSION (0) Key: JCRVLT-258 URL: https://issues.apache.org/jira/browse/JCRVLT-258 Project: Jackrabbit FileVault Issue Type: Bug Components: Packaging Affects Versions: 3.1.40 Reporter: Konrad Windszus Default compression level has been changed in this commit from -1 (Deflater#DEFAULT_COMPRESSION) to DEFLATER#NO_COMPRESSION (0): https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40 The original patch from JCRVLT-163 contained -1 (which was IMHO correct and is also more in line on how packages have been created prior to JCRVLT-163). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315901#comment-16315901
]
Dirk Rudolph commented on JCRVLT-257:
-
Its not because the new behaviour is not taken into account for that:
{code}
* The exporter can optimize the export throughput for binaries, by avoiding to
* compress incompressible binaries.
* The optimization is enabled for all {@link Deflater} compression levels but
* {@link Deflater#DEFAULT_COMPRESSION}, {@link Deflater#NO_COMPRESSION} and
* {@link Deflater#BEST_COMPRESSION}.
{code}
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel
> Version 17.3.0: Thu Nov 9 18:09:22 PST 2017;
> root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-258) Default compression level incorrectly set to NO_COMPRESSION (0)
[
https://issues.apache.org/jira/browse/JCRVLT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315905#comment-16315905
]
Timothee Maret commented on JCRVLT-258:
---
The default compression level was set on purpose to {{DEFAULT_COMPRESSION}} in
JCRVLT-163 in order to keep the same expectations regarding the compression
level as it was before JCRVLT-163.
I think it is important to set it back to {{DEFAULT_COMPRESSION}} because it is
... a good default choice which fits well with a "generic" feature such as the
Package Manager. Optimising for space or speed is use case specific IMO.
One example of negative side effect of using {{NO_COMPRESSION}} by default, is
the increase size of content packages shipped in AEM.
+1 for setting back the default compression level to {{DEFAULT_COMPRESSION}}.
> Default compression level incorrectly set to NO_COMPRESSION (0)
> ---
>
> Key: JCRVLT-258
> URL: https://issues.apache.org/jira/browse/JCRVLT-258
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40
>Reporter: Konrad Windszus
>
> Default compression level has been changed in this commit from
> {{Deflater#DEFAULT_COMPRESSION}} (-1) to {{DEFLATER#NO_COMPRESSION}} (0):
> https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
> The original patch from JCRVLT-163 contained -1 (which was IMHO correct and
> is also more in line on how packages have been created prior to JCRVLT-163).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315930#comment-16315930
]
Timothee Maret commented on JCRVLT-257:
---
[~diru] I ran your unit test at
https://github.com/Buuhuu/jackrabbit-filevault/commit/ddf685b4f8ba930ecfc77286eeb1f49a4f2be25a
However, the test passes successfully on my box. Could you give us more details
regarding how you run the tests, and about the environment you run the test on ?
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel
> Version 17.3.0: Thu Nov 9 18:09:22 PST 2017;
> root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JCRVLT-259) Support pluggable compression formats
Dirk Rudolph created JCRVLT-259: --- Summary: Support pluggable compression formats Key: JCRVLT-259 URL: https://issues.apache.org/jira/browse/JCRVLT-259 Project: Jackrabbit FileVault Issue Type: New Feature Components: Packaging Reporter: Dirk Rudolph The new feature to suppress compression for already compressed binaries introduced in JCRVLT-163, has been implemented with Apache Sling Content Distribution in mind to get best performance while still keep bytes on the wire as small as affordable [0]. Wouldn't it make sense for such cases to support different formats as well, especially thinking about snappy or lz4? Currently there is a pair for compressing and decompressing implementations, JarExporter and ZipArchive/ZipStreamArchive. Those are used by the PackageManagerImpl for example to open or assemble a new package. Adding support for further compression formats could be done for example by implementing a registry holding the constructors for compression and decompression implementations, where the one of choice could be requested by the ExportOptions (defaulting to jar/zip as it is now). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated JCRVLT-257:
Environment:
uname -a
Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9
18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
zip --version
Compiled with gcc 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31) for Unix
(Mac OS X) on Jul 15 2017.
java -version
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
was:
Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9
18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> zip --version
> Compiled with gcc 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31) for Unix
> (Mac OS X) on Jul 15 2017.
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated JCRVLT-257:
Environment:
uname -a
Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9
18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
zip --version
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Compiled with gcc 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31) for Unix
(Mac OS X) on Jul 15 2017.
java -version
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
was:
uname -a
Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9
18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
zip --version
Compiled with gcc 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31) for Unix
(Mac OS X) on Jul 15 2017.
java -version
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> zip --version
> This is Zip 3.0 (July 5th 2008), by Info-ZIP.
> Compiled with gcc 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31) for Unix
> (Mac OS X) on Jul 15 2017.
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315914#comment-16315914
]
Timothee Maret commented on JCRVLT-257:
---
Ok, thanks [~diru]! I'll have a look at your unit test.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel
> Version 17.3.0: Thu Nov 9 18:09:22 PST 2017;
> root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315886#comment-16315886
]
Timothee Maret commented on JCRVLT-257:
---
Ok.. just noticed (JCRVLT-258) opened by [~kwin] (our comments crossed).
So, The default for CRX Package Manager should not be no compression IMO, and
be reverted back to {{DEFAULT_COMPRESSION}}. Indeed, using {{NO_COMPRESSION}}
CRX Package Manager has impact on the size (size increase) of the packages
created down the line in AEM and other consumers, which is IMO not something we
want.
Sling SCD will still use {{BEST_SPEED}} as default, which is what we need.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel
> Version 17.3.0: Thu Nov 9 18:09:22 PST 2017;
> root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated JCRVLT-257:
Environment:
uname -a
Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9
18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
java -version
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
was:
uname -a
Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9
18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
zip --version
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Compiled with gcc 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31) for Unix
(Mac OS X) on Jul 15 2017.
java -version
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315883#comment-16315883
]
Timothee Maret commented on JCRVLT-257:
---
bq. and for those using Adobes CRX Package Manager, its using the default
option, being NO_COMPRESSION.
[~diru] Does CRX Package Manager really use NO_COMPRESSION or rather
{{DEFAULT_COMPRESSION}} ?
Assuming the latter, could you please test if the {{ZipException}} is thrown in
your initial setup with {{DEFAULT_COMPRESSION}} ?
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel
> Version 17.3.0: Thu Nov 9 18:09:22 PST 2017;
> root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-163) Avoid compressing incompressible binaries
[
https://issues.apache.org/jira/browse/JCRVLT-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315884#comment-16315884
]
Dirk Rudolph commented on JCRVLT-163:
-
I did a quick search on the difference between NO_COMPRESSION and the STORED
method and found:
https://stackoverflow.com/questions/35141580/zipentry-stored-for-files-that-are-already-compressed
{quote}
The ZipOutputStream.setLevel(NO_COMPRESSION/DEFAULT_COMPRESSION) hack is not a
viable approach. I did extensive tests on hundreds of gigs of data, thousands
of folders and files and the measurements were conclusive. It gains nothing
over calculating the CRC for the STORED files vs compressing them at
NO_COMPRESSION. It is actually slower by a large margin!
{quote}
> Avoid compressing incompressible binaries
> -
>
> Key: JCRVLT-163
> URL: https://issues.apache.org/jira/browse/JCRVLT-163
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.0
>Reporter: Timothee Maret
> Fix For: 3.1.40
>
> Attachments: JCRVLT-163.patch
>
>
> As discussed in [0], this issue tracks allowing to specify the compression
> level when building packages. The primary idea is to avoid compressing
> (compression level = {{NO_COMPRESSION}}) already compressed binaries,
> identified based on their MIME type.
> Setting the compression level is a tradeoff between the compression speed and
> the size of the compressed artefacts.
> Different use cases likely favour maximising either of the two.
> Therefor, it may make sense to allow configuring the compression levels per
> use case (not globally).
> A generic way to express this configuration would be:
> * a mapping from MIME type to compression level
> * the default level (for MIME type not matching any entry in the mapping)
> [0] https://www.mail-archive.com/dev@jackrabbit.apache.org/msg37807.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315940#comment-16315940
]
Dirk Rudolph commented on JCRVLT-257:
-
Its MacOS X 10.13.2 with java 1.8.0 151-b12 and zlib 1.2.11 according to the
MacOSX SDK 10.13 (assuming that the jre is using zlib). The test is failing
with both intellij and mvn.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315940#comment-16315940
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/8/18 9:34 AM:
-
Its MacOS X 10.13.2 with java 1.8.0 151-b12 and zlib 1.2.11 according to the
MacOSX SDK 10.13 (assuming that the jre is using zlib). The test is failing
with both intellij and mvn.
(In the commit the test is @Ignore d.)
was (Author: diru):
Its MacOS X 10.13.2 with java 1.8.0 151-b12 and zlib 1.2.11 according to the
MacOSX SDK 10.13 (assuming that the jre is using zlib). The test is failing
with both intellij and mvn.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315949#comment-16315949
]
Dirk Rudolph commented on JCRVLT-257:
-
This might be related: https://github.com/madler/zlib/issues/305
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315949#comment-16315949
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/8/18 9:38 AM:
-
This might be related: https://github.com/madler/zlib/issues/305
{quote}
I was able to track down the problem to a potential bug in the zlib version
shipped with High Sierra (1.12.11). Version 1.2.5 which is used in Sierra works
find. The bug is caused by changing the compression levels for different
entries.
{quote}
was (Author: diru):
This might be related: https://github.com/madler/zlib/issues/305
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315969#comment-16315969
]
Timothee Maret commented on JCRVLT-257:
---
bq. This might be related: https://github.com/madler/zlib/issues/305
Possibly, in which case, IIUC your test fails on your environment due to a zlib
bug.
Since on my environment, the test still passes successfully, I would suggest to
1. Update your environment with a version of zlib that contains the fix for
https://github.com/madler/zlib/issues/305
2. Rework the unit test until it produce the ZipException
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315949#comment-16315949
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/8/18 9:48 AM:
-
This might be related: https://github.com/madler/zlib/issues/305
{quote}
I was able to track down the problem to a potential bug in the zlib version
shipped with High Sierra (1.12.11). Version 1.2.5 which is used in Sierra works
find. The bug is caused by changing the compression levels for different
entries.
{quote}
https://bugs.openjdk.java.net/browse/JDK-8184306
was (Author: diru):
This might be related: https://github.com/madler/zlib/issues/305
{quote}
I was able to track down the problem to a potential bug in the zlib version
shipped with High Sierra (1.12.11). Version 1.2.5 which is used in Sierra works
find. The bug is caused by changing the compression levels for different
entries.
{quote}
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-258) Default compression level incorrectly set to NO_COMPRESSION (0)
[
https://issues.apache.org/jira/browse/JCRVLT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315905#comment-16315905
]
Timothee Maret edited comment on JCRVLT-258 at 1/8/18 9:51 AM:
---
The default compression level was set on purpose to {{DEFAULT_COMPRESSION}} in
JCRVLT-163 in order to keep the same expectations regarding the compression
level as it was before JCRVLT-163.
I think it is important to set it back to {{DEFAULT_COMPRESSION}} because it is
... a good default choice which fits well with a "generic" feature such as the
Package Manager. Optimising for space or speed is use case specific IMO.
One example of negative side effect of using {{NO_COMPRESSION}} by default, is
the increase size of content packages shipped in AEM.
+1 for setting back the default compression level to {{DEFAULT_COMPRESSION}}.
cc [~tripod]
was (Author: marett):
The default compression level was set on purpose to {{DEFAULT_COMPRESSION}} in
JCRVLT-163 in order to keep the same expectations regarding the compression
level as it was before JCRVLT-163.
I think it is important to set it back to {{DEFAULT_COMPRESSION}} because it is
... a good default choice which fits well with a "generic" feature such as the
Package Manager. Optimising for space or speed is use case specific IMO.
One example of negative side effect of using {{NO_COMPRESSION}} by default, is
the increase size of content packages shipped in AEM.
+1 for setting back the default compression level to {{DEFAULT_COMPRESSION}}.
> Default compression level incorrectly set to NO_COMPRESSION (0)
> ---
>
> Key: JCRVLT-258
> URL: https://issues.apache.org/jira/browse/JCRVLT-258
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40
>Reporter: Konrad Windszus
>
> Default compression level has been changed in this commit from
> {{Deflater#DEFAULT_COMPRESSION}} (-1) to {{DEFLATER#NO_COMPRESSION}} (0):
> https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
> The original patch from JCRVLT-163 contained -1 (which was IMHO correct and
> is also more in line on how packages have been created prior to JCRVLT-163).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316008#comment-16316008
]
Dirk Rudolph commented on JCRVLT-257:
-
Well changing the zlib version shipped by my operation system is nothing I want
to do on my personal computer, nor in production like environments.
The bug in the jdk looks like being resolved with java9 only. In the mean while
more distributions (esp. linux, windows runs with a statically linked zlib,
macosx high sierra already has 1.2.11) will bring updates to 1.2.11, and users
will start facing that error. The only places I know atm are Sling Content
Distribution (failing) and CRX Package Manager (not failing due to DEFAULT not
NO COMPRESSION).
So to resolve the issue I see the following options:
1) don't switch compression level, when we know we are running on and
environment that is effected by JDK-8184306 (not sure how to check that)
2) allow turning of switching compression level by a system configuration
property (kind of a feature flag)
3) hand that in application logic (in my case Sling SCD)
Handling that in application logic sounds more like a workaround then actually
resolving that issue.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316009#comment-16316009
]
Konrad Windszus commented on JCRVLT-257:
I think this issue has been fixed/worked around in a newer Java version:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316009#comment-16316009
]
Konrad Windszus edited comment on JCRVLT-257 at 1/8/18 10:15 AM:
-
I think this issue has been fixed/worked around in a newer Java versions:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789. The problem though is
that neither Java 8u162 nor 7u171 nor Java 10 are released yet...
was (Author: kwin):
I think this issue has been fixed/worked around in a newer Java version:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316009#comment-16316009
]
Konrad Windszus edited comment on JCRVLT-257 at 1/8/18 10:22 AM:
-
I think this issue has been fixed/worked around in newer Java versions:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789. The problem though is
that neither Java 8u162 nor 7u171 nor Java 10 are released yet...
was (Author: kwin):
I think this issue has been fixed/worked around in a newer Java versions:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789. The problem though is
that neither Java 8u162 nor 7u171 nor Java 10 are released yet...
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316040#comment-16316040
]
Dirk Rudolph commented on JCRVLT-257:
-
Upgrading to 162 didn't resolve the issue so I guess its not JDK-8189789.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316040#comment-16316040
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/8/18 10:28 AM:
--
Upgrading to 1.8. b162 didn't resolve the issue so I guess its not JDK-8189789.
was (Author: diru):
Upgrading to 162 didn't resolve the issue so I guess its not JDK-8189789.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316040#comment-16316040
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/8/18 10:29 AM:
--
Upgrading to 1.8.0 b162 didn't resolve the issue so I guess its not JDK-8189789.
was (Author: diru):
Upgrading to 1.8. b162 didn't resolve the issue so I guess its not JDK-8189789.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316040#comment-16316040
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/8/18 10:35 AM:
--
Upgrading to 1.8.0 b162 didn't resolve the issue so I guess its not
JDK-8189789, nor does an update to 9.0.1+11
was (Author: diru):
Upgrading to 1.8.0 b162 didn't resolve the issue so I guess its not JDK-8189789.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316008#comment-16316008
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/8/18 10:35 AM:
--
Well changing the zlib version shipped by my operation system is nothing I want
to do on my personal computer, nor in production like environments.
The bug in the jdk looks like being resolved with java9 only. In the mean while
more distributions (esp. linux, windows runs with a statically linked zlib,
macosx high sierra already has 1.2.11) will bring updates to 1.2.11, and users
will start facing that error. The only places I know atm are Sling Content
Distribution (failing) and CRX Package Manager (not failing due to DEFAULT not
NO COMPRESSION).
So to resolve the issue I see the following options:
1) don't switch compression level, when we know we are running on an
environment that is effected by JDK-8184306 (not sure how to check that)
2) allow turning of switching compression level by a system configuration
property (kind of a feature flag)
3) hand that in application logic (in my case Sling SCD)
Handling that in application logic sounds more like a workaround then actually
resolving that issue.
was (Author: diru):
Well changing the zlib version shipped by my operation system is nothing I want
to do on my personal computer, nor in production like environments.
The bug in the jdk looks like being resolved with java9 only. In the mean while
more distributions (esp. linux, windows runs with a statically linked zlib,
macosx high sierra already has 1.2.11) will bring updates to 1.2.11, and users
will start facing that error. The only places I know atm are Sling Content
Distribution (failing) and CRX Package Manager (not failing due to DEFAULT not
NO COMPRESSION).
So to resolve the issue I see the following options:
1) don't switch compression level, when we know we are running on and
environment that is effected by JDK-8184306 (not sure how to check that)
2) allow turning of switching compression level by a system configuration
property (kind of a feature flag)
3) hand that in application logic (in my case Sling SCD)
Handling that in application logic sounds more like a workaround then actually
resolving that issue.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316008#comment-16316008
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/8/18 10:36 AM:
--
Well changing the zlib version shipped by my operation system is nothing I want
to do on my personal computer, nor in production like environments.
The bug in the jdk looks like being resolved with java9 only. In the mean while
more distributions (esp. linux, windows runs with a statically linked zlib,
macosx high sierra already has 1.2.11) will bring updates to 1.2.11, and users
will start facing that error. The only places I know atm are Sling Content
Distribution (failing) and CRX Package Manager (not failing due to DEFAULT not
NO COMPRESSION).
So to resolve the issue I see the following options:
1) don't switch compression level, when we know we are running on an
environment that is effected by JDK-8184306 (not sure how to check that)
2) allow turning of switching compression level by a system configuration
property (kind of a feature flag)
3) handle that in application logic (in my case Sling SCD)
Handling that in application logic sounds more like a workaround then actually
resolving that issue.
was (Author: diru):
Well changing the zlib version shipped by my operation system is nothing I want
to do on my personal computer, nor in production like environments.
The bug in the jdk looks like being resolved with java9 only. In the mean while
more distributions (esp. linux, windows runs with a statically linked zlib,
macosx high sierra already has 1.2.11) will bring updates to 1.2.11, and users
will start facing that error. The only places I know atm are Sling Content
Distribution (failing) and CRX Package Manager (not failing due to DEFAULT not
NO COMPRESSION).
So to resolve the issue I see the following options:
1) don't switch compression level, when we know we are running on an
environment that is effected by JDK-8184306 (not sure how to check that)
2) allow turning of switching compression level by a system configuration
property (kind of a feature flag)
3) hand that in application logic (in my case Sling SCD)
Handling that in application logic sounds more like a workaround then actually
resolving that issue.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316008#comment-16316008
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/8/18 10:38 AM:
--
Well changing the zlib version shipped by my operation system is nothing I want
to do on my personal computer, nor in production like environments.
The bug in the jdk looks like being resolved with java9 only. In the meanwhile
more distributions (esp. linux, windows runs with a statically linked zlib,
macosx high sierra already has 1.2.11) will bring updates to 1.2.11, and users
will start facing that error. The only places I know atm are Sling Content
Distribution (failing) and CRX Package Manager (not failing due to DEFAULT not
NO COMPRESSION).
So to resolve the issue I see the following options:
1) don't switch compression level, when we know we are running on an
environment that is effected by JDK-8184306 (not sure how to check that)
2) allow turning of switching compression level by a system configuration
property (kind of a feature flag)
3) handle that in application logic (in my case Sling SCD)
Handling that in application logic sounds more like a workaround then actually
resolving that issue.
was (Author: diru):
Well changing the zlib version shipped by my operation system is nothing I want
to do on my personal computer, nor in production like environments.
The bug in the jdk looks like being resolved with java9 only. In the mean while
more distributions (esp. linux, windows runs with a statically linked zlib,
macosx high sierra already has 1.2.11) will bring updates to 1.2.11, and users
will start facing that error. The only places I know atm are Sling Content
Distribution (failing) and CRX Package Manager (not failing due to DEFAULT not
NO COMPRESSION).
So to resolve the issue I see the following options:
1) don't switch compression level, when we know we are running on an
environment that is effected by JDK-8184306 (not sure how to check that)
2) allow turning of switching compression level by a system configuration
property (kind of a feature flag)
3) handle that in application logic (in my case Sling SCD)
Handling that in application logic sounds more like a workaround then actually
resolving that issue.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316080#comment-16316080
]
Konrad Windszus commented on JCRVLT-257:
The latest build (b03) of 8u162 is from October 2017. The fix though has been
applied in Nov. 2017
(http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/ and
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050118.html)
so we have to wait for a more recent build...
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316080#comment-16316080
]
Konrad Windszus edited comment on JCRVLT-257 at 1/8/18 10:57 AM:
-
The latest build (b03) of 8u162 is from October 2017. The fix though has been
applied in Nov. 2017
(http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/ and
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050118.html)
so we have to wait for a more recent build... 8u162 is supposed to be released
in Jan 2018 (http://openjdk.java.net/projects/jdk8u/releases/8u162.html).
was (Author: kwin):
The latest build (b03) of 8u162 is from October 2017. The fix though has been
applied in Nov. 2017
(http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/ and
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050118.html)
so we have to wait for a more recent build...
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated JCRVLT-257:
Environment:
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
zlib version 1.2.11
was:
uname -a
Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9
18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
java -version
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316124#comment-16316124
]
Konrad Windszus commented on JCRVLT-257:
The test from [~diru] fails on my machine with Java 8 (1.8.0_151) and 9 (9.0.1)
but works with Java 10 (ea37). So most probably the fix/workaround from Oracle
works.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316125#comment-16316125
]
Timothee Maret commented on JCRVLT-257:
---
In case the zlib fix takes a while to be included in most environments, I have
opened SLING-7362 which allows to configure the default compression level for
SCD.
With SLING-7362, SCD default would still BEST_SPEED, but there would be a way
to configure the SCD compression to a level not triggering the optimisation
(e.g. {{DEFAULT_COMPRESSION}}, {{NO_COMPRESSION}} or {{BEST_COMPRESSION}})
which seems to hit a zlib bug.
The issue JCRVLT-258 is a separate one and should still IMO be fixed.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316125#comment-16316125
]
Timothee Maret edited comment on JCRVLT-257 at 1/8/18 11:19 AM:
Thanks [~kwin] for your analysis!
In case the zlib fix takes a while to be included in most environments, I have
opened SLING-7362 which allows to configure the default compression level for
SCD.
With SLING-7362, SCD default would still BEST_SPEED, but there would be a way
to configure the SCD compression to a level not triggering the JCRVLT-163
optimisation (e.g. {{DEFAULT_COMPRESSION}}, {{NO_COMPRESSION}} or
{{BEST_COMPRESSION}}) and this avoid the zlib bug.
The issue JCRVLT-258 is a separate one and should still IMO be fixed.
was (Author: marett):
In case the zlib fix takes a while to be included in most environments, I have
opened SLING-7362 which allows to configure the default compression level for
SCD.
With SLING-7362, SCD default would still BEST_SPEED, but there would be a way
to configure the SCD compression to a level not triggering the optimisation
(e.g. {{DEFAULT_COMPRESSION}}, {{NO_COMPRESSION}} or {{BEST_COMPRESSION}})
which seems to hit a zlib bug.
The issue JCRVLT-258 is a separate one and should still IMO be fixed.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316125#comment-16316125
]
Timothee Maret edited comment on JCRVLT-257 at 1/8/18 11:25 AM:
Thanks [~kwin] for your analysis!
In case the zlib fix takes a while to be included in most environments, I have
opened SLING-7362 which allows to configure the default compression level for
SCD.
With SLING-7362, SCD default would still BEST_SPEED, but there would be a way
to configure the SCD compression to a level not trigger the JCRVLT-163
optimisation (e.g. {{DEFAULT_COMPRESSION}}, {{NO_COMPRESSION}} or
{{BEST_COMPRESSION}}) and thus avoid the zlib bug.
The issue JCRVLT-258 is a separate one and should still IMO be fixed.
was (Author: marett):
Thanks [~kwin] for your analysis!
In case the zlib fix takes a while to be included in most environments, I have
opened SLING-7362 which allows to configure the default compression level for
SCD.
With SLING-7362, SCD default would still BEST_SPEED, but there would be a way
to configure the SCD compression to a level not triggering the JCRVLT-163
optimisation (e.g. {{DEFAULT_COMPRESSION}}, {{NO_COMPRESSION}} or
{{BEST_COMPRESSION}}) and this avoid the zlib bug.
The issue JCRVLT-258 is a separate one and should still IMO be fixed.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-258) Default compression level incorrectly set to NO_COMPRESSION (0)
[
https://issues.apache.org/jira/browse/JCRVLT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316137#comment-16316137
]
Konrad Windszus commented on JCRVLT-258:
Just switching the default to {{DEFAULT_COMPRESSION}} will trigger the issue
observed in JCRVLT-257 (at least on more recent Unix systems, leveraging a more
recent zlib library). So at least a detection for the faulty zlib/java version
must be included.
> Default compression level incorrectly set to NO_COMPRESSION (0)
> ---
>
> Key: JCRVLT-258
> URL: https://issues.apache.org/jira/browse/JCRVLT-258
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40
>Reporter: Konrad Windszus
>
> Default compression level has been changed in this commit from
> {{Deflater#DEFAULT_COMPRESSION}} (-1) to {{DEFLATER#NO_COMPRESSION}} (0):
> https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
> The original patch from JCRVLT-163 contained -1 (which was IMHO correct and
> is also more in line on how packages have been created prior to JCRVLT-163).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316009#comment-16316009
]
Konrad Windszus edited comment on JCRVLT-257 at 1/8/18 11:30 AM:
-
I think this issue has been fixed/worked around in newer Java versions:
https://bugs.openjdk.java.net/browse/JDK-8189789. The problem though is that
neither Java 8u162 nor 7u171 nor Java 10 are released yet...
was (Author: kwin):
I think this issue has been fixed/worked around in newer Java versions:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789. The problem though is
that neither Java 8u162 nor 7u171 nor Java 10 are released yet...
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCR-4001) When using Node.getProperties(String namePattern) also child nodes are processed
[ https://issues.apache.org/jira/browse/JCR-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316168#comment-16316168 ] Luca Tagliani commented on JCR-4001: Are there any possibility that this patch could be merged on trunk for next release? > When using Node.getProperties(String namePattern) also child nodes are > processed > > > Key: JCR-4001 > URL: https://issues.apache.org/jira/browse/JCR-4001 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-commons >Affects Versions: 2.12.2 >Reporter: Luca Tagliani > Attachments: JCR-4001.patch > > > Call to Node.getProperties(String namePattern) processed also child nodes and > not only properties. > This can deteriorate performance when there are lots of children. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCR-4001) When using Node.getProperties(String namePattern) also child nodes are processed
[ https://issues.apache.org/jira/browse/JCR-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316195#comment-16316195 ] Julian Reschke commented on JCR-4001: - I'll have a look, but I can't promise yet when... > When using Node.getProperties(String namePattern) also child nodes are > processed > > > Key: JCR-4001 > URL: https://issues.apache.org/jira/browse/JCR-4001 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-commons >Affects Versions: 2.12.2 >Reporter: Luca Tagliani >Assignee: Julian Reschke > Attachments: JCR-4001.patch > > > Call to Node.getProperties(String namePattern) processed also child nodes and > not only properties. > This can deteriorate performance when there are lots of children. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (JCR-4001) When using Node.getProperties(String namePattern) also child nodes are processed
[ https://issues.apache.org/jira/browse/JCR-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke reassigned JCR-4001: --- Assignee: Julian Reschke > When using Node.getProperties(String namePattern) also child nodes are > processed > > > Key: JCR-4001 > URL: https://issues.apache.org/jira/browse/JCR-4001 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-commons >Affects Versions: 2.12.2 >Reporter: Luca Tagliani >Assignee: Julian Reschke > Attachments: JCR-4001.patch > > > Call to Node.getProperties(String namePattern) processed also child nodes and > not only properties. > This can deteriorate performance when there are lots of children. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCR-4001) When using Node.getProperties(String namePattern) also child nodes are processed
[ https://issues.apache.org/jira/browse/JCR-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-4001: Issue Type: Improvement (was: Bug) > When using Node.getProperties(String namePattern) also child nodes are > processed > > > Key: JCR-4001 > URL: https://issues.apache.org/jira/browse/JCR-4001 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Reporter: Luca Tagliani >Assignee: Julian Reschke > Attachments: JCR-4001.patch > > > Call to Node.getProperties(String namePattern) processed also child nodes and > not only properties. > This can deteriorate performance when there are lots of children. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCR-4001) When using Node.getProperties(String namePattern) also child nodes are processed
[ https://issues.apache.org/jira/browse/JCR-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-4001: Affects Version/s: (was: 2.12.2) > When using Node.getProperties(String namePattern) also child nodes are > processed > > > Key: JCR-4001 > URL: https://issues.apache.org/jira/browse/JCR-4001 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Reporter: Luca Tagliani >Assignee: Julian Reschke > Attachments: JCR-4001.patch > > > Call to Node.getProperties(String namePattern) processed also child nodes and > not only properties. > This can deteriorate performance when there are lots of children. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316233#comment-16316233
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/8/18 12:40 PM:
--
I discussed that further with [~kwin] and we think the check proposed in issue
305 makes sense to verify if an environment supports changing the compression
level or not. I implemented that in
https://github.com/apache/jackrabbit-filevault/pull/20 resolving the issue for
me.
was (Author: diru):
I discussed that further with [~kwin] and we think the check proposed in issue
305 makes sense to verify if an environment supports changing the compression
level or not. I implemented that in
https://github.com/apache/jackrabbit-filevault/pull/20.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316233#comment-16316233
]
Dirk Rudolph commented on JCRVLT-257:
-
I discussed that further with [~kwin] and we think the check proposed in issue
305 makes sense to verify if an environment supports changing the compression
level or not. I implemented that in
https://github.com/apache/jackrabbit-filevault/pull/20.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316233#comment-16316233
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/8/18 12:40 PM:
--
I discussed that further with [~kwin] and we think the check proposed in issue
305 makes sense to verify if an environment supports changing the compression
level or not. I implemented that in
https://github.com/apache/jackrabbit-filevault/pull/20 resolving the issue for
me (the scenarios written above).
was (Author: diru):
I discussed that further with [~kwin] and we think the check proposed in issue
305 makes sense to verify if an environment supports changing the compression
level or not. I implemented that in
https://github.com/apache/jackrabbit-filevault/pull/20 resolving the issue for
me.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated JCRVLT-257:
Affects Version/s: 3.1.42
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40, 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Rudolph updated JCRVLT-257:
Affects Version/s: (was: 3.1.42)
3.1.40
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40, 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (JCRSITE-50) broken link to ezmlm documentation
[ https://issues.apache.org/jira/browse/JCRSITE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned JCRSITE-50: --- Assignee: Marcel Reutegger > broken link to ezmlm documentation > -- > > Key: JCRSITE-50 > URL: https://issues.apache.org/jira/browse/JCRSITE-50 > Project: Jackrabbit Site > Issue Type: Bug >Reporter: Jörg Hoh >Assignee: Marcel Reutegger > > on http://jackrabbit.apache.org/jcr/mailing-lists.html there are 3 links > pointing to the site ezmlm.org, which are supposed to point to documentation > for subscription/unsubscription. > Looks like ezmlm has changed the owner (and the content); I don't think that > these links are still useful. We should drop them. IMO the documentation at > http://www.apache.org/foundation/mailinglists.html for > subscription/unsubscription is sufficient. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCRSITE-50) Broken link to ezmlm documentation
[ https://issues.apache.org/jira/browse/JCRSITE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCRSITE-50: Summary: Broken link to ezmlm documentation (was: broken link to ezmlm documentation) > Broken link to ezmlm documentation > -- > > Key: JCRSITE-50 > URL: https://issues.apache.org/jira/browse/JCRSITE-50 > Project: Jackrabbit Site > Issue Type: Bug >Reporter: Jörg Hoh >Assignee: Marcel Reutegger > > on http://jackrabbit.apache.org/jcr/mailing-lists.html there are 3 links > pointing to the site ezmlm.org, which are supposed to point to documentation > for subscription/unsubscription. > Looks like ezmlm has changed the owner (and the content); I don't think that > these links are still useful. We should drop them. IMO the documentation at > http://www.apache.org/foundation/mailinglists.html for > subscription/unsubscription is sufficient. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (JCRSITE-50) Broken link to ezmlm documentation
[ https://issues.apache.org/jira/browse/JCRSITE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCRSITE-50. - Resolution: Fixed Updated the links pointing to the new ezmlm home: http://svn.apache.org/r1820556 > Broken link to ezmlm documentation > -- > > Key: JCRSITE-50 > URL: https://issues.apache.org/jira/browse/JCRSITE-50 > Project: Jackrabbit Site > Issue Type: Bug >Reporter: Jörg Hoh >Assignee: Marcel Reutegger > > on http://jackrabbit.apache.org/jcr/mailing-lists.html there are 3 links > pointing to the site ezmlm.org, which are supposed to point to documentation > for subscription/unsubscription. > Looks like ezmlm has changed the owner (and the content); I don't think that > these links are still useful. We should drop them. IMO the documentation at > http://www.apache.org/foundation/mailinglists.html for > subscription/unsubscription is sufficient. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCR-4001) When using Node.getProperties(String namePattern) also child nodes are processed
[
https://issues.apache.org/jira/browse/JCR-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316452#comment-16316452
]
Julian Reschke commented on JCR-4001:
-
I agree that this should be improved. The proposed patch essentially
re-implements {{TraversingItemVisitor.Default}} (which is part javax.jcr).
It might be simpler though to change the property collectors not to use the
visitor pattern at all.
> When using Node.getProperties(String namePattern) also child nodes are
> processed
>
>
> Key: JCR-4001
> URL: https://issues.apache.org/jira/browse/JCR-4001
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
>Reporter: Luca Tagliani
>Assignee: Julian Reschke
> Attachments: JCR-4001.patch
>
>
> Call to Node.getProperties(String namePattern) processed also child nodes and
> not only properties.
> This can deteriorate performance when there are lots of children.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JCR-4244) Upgrade tomcat dependency to 8.5.24
Julian Reschke created JCR-4244: --- Summary: Upgrade tomcat dependency to 8.5.24 Key: JCR-4244 URL: https://issues.apache.org/jira/browse/JCR-4244 Project: Jackrabbit Content Repository Issue Type: Task Components: jackrabbit-webapp Reporter: Julian Reschke -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (JCR-4244) Upgrade tomcat dependency to 8.5.24
[ https://issues.apache.org/jira/browse/JCR-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-4244. - Resolution: Fixed Assignee: Julian Reschke Fix Version/s: 2.17.1 2.18 > Upgrade tomcat dependency to 8.5.24 > --- > > Key: JCR-4244 > URL: https://issues.apache.org/jira/browse/JCR-4244 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-webapp >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 2.18, 2.17.1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCR-4244) Upgrade tomcat dependency to 8.5.24
[ https://issues.apache.org/jira/browse/JCR-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316506#comment-16316506 ] Julian Reschke commented on JCR-4244: - trunk: [r1820573|http://svn.apache.org/r1820573] > Upgrade tomcat dependency to 8.5.24 > --- > > Key: JCR-4244 > URL: https://issues.apache.org/jira/browse/JCR-4244 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-webapp >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 2.18, 2.17.1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCR-4244) Upgrade tomcat dependency to 8.5.24
[ https://issues.apache.org/jira/browse/JCR-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-4244: Labels: candidate_jcr_2_16 (was: ) > Upgrade tomcat dependency to 8.5.24 > --- > > Key: JCR-4244 > URL: https://issues.apache.org/jira/browse/JCR-4244 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-webapp >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: candidate_jcr_2_16 > Fix For: 2.18, 2.17.1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned JCRVLT-257:
---
Assignee: Tobias Bocanegra
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40, 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Assignee: Tobias Bocanegra
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCRVLT-257.
-
Resolution: Fixed
Fix Version/s: 3.1.44
Thanks for the patch, [~diru]. I applied the change (with small modifications)
in r1820625
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40, 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Assignee: Tobias Bocanegra
>Priority: Critical
> Fix For: 3.1.44
>
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (JCRVLT-258) Default compression level incorrectly set to NO_COMPRESSION (0)
[
https://issues.apache.org/jira/browse/JCRVLT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned JCRVLT-258:
---
Assignee: Tobias Bocanegra
> Default compression level incorrectly set to NO_COMPRESSION (0)
> ---
>
> Key: JCRVLT-258
> URL: https://issues.apache.org/jira/browse/JCRVLT-258
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Default compression level has been changed in this commit from
> {{Deflater#DEFAULT_COMPRESSION}} (-1) to {{DEFLATER#NO_COMPRESSION}} (0):
> https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
> The original patch from JCRVLT-163 contained -1 (which was IMHO correct and
> is also more in line on how packages have been created prior to JCRVLT-163).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (JCRVLT-258) Default compression level incorrectly set to NO_COMPRESSION (0)
[
https://issues.apache.org/jira/browse/JCRVLT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCRVLT-258.
-
Resolution: Fixed
Fix Version/s: 3.1.44
fixed in r1820626
> Default compression level incorrectly set to NO_COMPRESSION (0)
> ---
>
> Key: JCRVLT-258
> URL: https://issues.apache.org/jira/browse/JCRVLT-258
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
> Fix For: 3.1.44
>
>
> Default compression level has been changed in this commit from
> {{Deflater#DEFAULT_COMPRESSION}} (-1) to {{DEFLATER#NO_COMPRESSION}} (0):
> https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
> The original patch from JCRVLT-163 contained -1 (which was IMHO correct and
> is also more in line on how packages have been created prior to JCRVLT-163).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
