[
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)
