[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=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] [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=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] [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=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] [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=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] [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=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=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] [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=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] [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=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=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=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=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=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=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] [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=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=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-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [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=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] [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=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] [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=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] [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=16315405#comment-16315405
]
Dirk Rudolph edited comment on JCRVLT-257 at 1/7/18 6:03 PM:
-
See the attached zip file, exported with 3.1.42, and what {{unzip}} says about
it:
{code}
Dirks-MacBook-Pro:test dirk.rudolph$ unzip distributionpackage.zip
Archive: distributionpackage.zip
inflating: META-INF/MANIFEST.MF
creating: META-INF/vault/
inflating: META-INF/vault/properties.xml
inflating: META-INF/vault/config.xml
inflating: META-INF/vault/filter.xml
inflating: jcr_root/.content.xml
creating: jcr_root/content/
inflating: jcr_root/content/.content.xml
creating: jcr_root/content/dam/
inflating: jcr_root/content/dam/.content.xml
creating: jcr_root/content/dam/DSC_0106.jpg/
creating: jcr_root/content/dam/DSC_0106.jpg/_jcr_content/
creating: jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.48.48.png
error: invalid compressed data to inflate
creating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.48.48.png.dir/
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.48.48.png.dir/.content.xml
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.140.100.png
error: invalid compressed data to inflate
creating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.140.100.png.dir/
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.140.100.png.dir/.content.xml
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.web.1280.1280.jpeg
error: invalid compressed data to inflate
creating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.web.1280.1280.jpeg.dir/
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.web.1280.1280.jpeg.dir/.content.xml
inflating: jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/original
bad CRC 7aef5aa6 (should be 0ebac2d8)
creating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/original.dir/
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/original.dir/.content.xml
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.319.319.png
error: invalid compressed data to inflate
creating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.319.319.png.dir/
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.319.319.png.dir/.content.xml
inflating: jcr_root/content/dam/DSC_0106.jpg/.content.xml
inflating: META-INF/vault/nodetypes.cnd
{code}
was (Author: diru):
See the attached zip file, exported with 3.1.42, and what {{unzip}} says about
it:
{code}
Dirks-MacBook-Pro:test dirk.rudolph$ unzip jcr%3acontent
Archive: jcr%3acontent
inflating: META-INF/MANIFEST.MF
creating: META-INF/vault/
inflating: META-INF/vault/properties.xml
inflating: META-INF/vault/config.xml
inflating: META-INF/vault/filter.xml
inflating: jcr_root/.content.xml
creating: jcr_root/content/
inflating: jcr_root/content/.content.xml
creating: jcr_root/content/dam/
inflating: jcr_root/content/dam/.content.xml
creating: jcr_root/content/dam/DSC_0106.jpg/
creating: jcr_root/content/dam/DSC_0106.jpg/_jcr_content/
creating: jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.48.48.png
error: invalid compressed data to inflate
creating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.48.48.png.dir/
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.48.48.png.dir/.content.xml
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.140.100.png
error: invalid compressed data to inflate
creating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.140.100.png.dir/
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.thumbnail.140.100.png.dir/.content.xml
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.web.1280.1280.jpeg
error: invalid compressed data to inflate
creating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.web.1280.1280.jpeg.dir/
inflating:
jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/cq5dam.web.1280.1280.jpeg.dir/.content.xml
inflating: jcr_root/content/dam/DSC_0106.jpg/_jcr_content/renditions/original
bad CRC 7aef5aa6 (should be 0ebac2d8)
creating:
