Reputation: 429
I noticed while working with GZIPInputStream that using an InputStream generated from Class.class.getResourceAsStream on a gzipped file causes a
java.util.zip.ZipException: invalid code lengths set
when used in GZIPInputStream, but using a FileInputStream on the same file seems to work fine. Does anyone know what is causing this?
For example:
InputStream is = new FileInputStream("src/main/resources/testFile.gz");
GZIPInputStream zis = new GZIPInputStream(is);
String outputStr = IOUtils.toString(zis, "utf-8");
Successfully generates an output string with the unzipped file data, while:
InputStream is = Class.class.getResourceAsStream("/testFile.gz");
GZIPInputStream zis = new GZIPInputStream(is);
String outputStr = IOUtils.toString(zis, "utf-8");
Generates the ZipException above.
I when I un-gzip the file I am able to get the correct outputString using IOUtils.toString on the InputStream generated either way so I know that the file is being accessed successfully and the issue appears to be with GZIPInputStream its self.
Upvotes: 0
Views: 1113
Reputation: 429
It turns out Maven is the culprit behind why using getResourceAsStream was generating a ZipException while FileInputStream was not. The gz files I had under src/main/resources were being copied to target/src/main/resources by Maven, and were subsequently auto corrupted when Maven filtering was applied. FileInputStream was targeting the file under src/main/resources while getResourceAsStream was targeting the file under target/src/main/resources. The solution to the issue was to disable filtering for my resources in the src/main/resources directory as follows.
<resource>
<directory>src/main/resources</directory>
<includes>
<include>**/*</include>
</includes>
<filtering>false</filtering>
</resource>
Upvotes: 1