I have a Jar file, which contains other nested Jars. When I invoke the new JarFile() constructor on this file, I get an exception which says:
java.util.zip.ZipException: error in opening zip file
When I manually unzip the contents of this Jar file and zip it up again, it works fine.
I only see this exception on WebSphere 6.1.0.7 and higher versions. The same thing works fine on tomcat and WebLogic.
When I use JarInputStream instead of JarFile, I am able to read the contents of the Jar file without any exceptions.
It could be related to log4j.
Do you have log4j.jar file in the websphere java classpath (as defined in the startup file) as well as the application classpath ?
If you do make sure that the log4j.jar file is in the java classpath and that it is NOT in the web-inf/lib directory of your webapp.
It can also be related with the ant version (may be not your case, but I do put it here for reference):
You have a .class file in your class path (i.e. not a directory or a .jar file). Starting with ant 1.6, ant will open the files in the classpath checking for manifest entries. This attempted opening will fail with the error "java.util.zip.ZipException"
The problem does not exist with ant 1.5 as it does not try to open the files. - so make sure that your classpath's do not contain .class files.
On a side note, did you consider having separate jars ?
You could in the manifest of your main jar, refer to the other jars with this attribute:
Class-Path: one.jar two.jar three.jar
Then, place all of your jars in the same folder.
Again, may be not valid for your case, but still there for reference.
In my case SL4j-api.jar with multiple versions are conflicting in the maven repo. Than I deleted the entire SL4j-api folder in m2 maven repo and updated maven project, build maven project than ran the project in JBOSS server. issue got resolved.
I've seen this exception before when whatever the JVM considers to be a temp directory is not accessible due to not being there or not having permission to write.
Simply to overcome the ZipException's, i have used a wrapper for commons-compress1.14 called jarchivelibwritten by thrau that makes it easy to extract or compress from and into File objects.
Example:
public static void main(String[] args) {
String zipfilePath =
"E:/Selenium_Server/geckodriver-v0.19.0-linux64.tar.gz";
//"E:/Selenium_Server/geckodriver-v0.19.0-win32.zip";
String outdir = "E:/Selenium_Server/";
exratctFileList(zipfilePath, outdir );
}
public void exratctFileList( String zipfilePath, String outdir ) throws IOException {
File archive = new File( zipfilePath );
File destinationDir = new File( outdir );
Archiver archiver = null;
if( zipfilePath.endsWith(".zip") ) {
archiver = ArchiverFactory.createArchiver( ArchiveFormat.ZIP );
} else if ( zipfilePath.endsWith(".tar.gz") ) {
archiver = ArchiverFactory.createArchiver( ArchiveFormat.TAR, CompressionType.GZIP );
}
archiver.extract(archive, destinationDir);
ArchiveStream stream = archiver.stream( archive );
ArchiveEntry entry;
while( (entry = stream.getNextEntry()) != null ) {
String entryName = entry.getName();
System.out.println("Entery Name : "+ entryName );
}
stream.close();
}
Maven dependency « You can download the jars from the Sonatype Maven Repository at org/rauschig/jarchivelib/.
<dependency>
<groupId>org.rauschig</groupId>
<artifactId>jarchivelib</artifactId>
<version>0.7.1</version>
</dependency>
@see
In my case SL4j-api.jar with multiple versions are conflicting in the maven repo. Than I deleted the entire SL4j-api folder in m2 maven repo and updated maven project, build maven project than ran the project in JBOSS server. issue got resolved.
I've seen this exception before when whatever the JVM considers to be a temp directory is not accessible due to not being there or not having permission to write.
Make sure your jar file is not corrupted. If it's corrupted or not able to unzip, this error will occur.
I solved this by clearing the jboss-x.y.z/server[config]/tmp and jboss-x.y.z/server/[config]/work directories.
I faced the same problem. I had a zip archive which java.util.zip.ZipFile was not able to handle but WinRar unpacked it just fine. I found article on SDN about compressing and decompressing options in Java. I slightly modified one of example codes to produce method which was finally capable of handling the archive. Trick is in using ZipInputStream instead of ZipFile and in sequential reading of zip archive. This method is also capable of handling empty zip archive. I believe you can adjust the method to suit your needs as all zip classes have equivalent subclasses for .jar archives.
public void unzipFileIntoDirectory(File archive, File destinationDir)
throws Exception {
final int BUFFER_SIZE = 1024;
BufferedOutputStream dest = null;
FileInputStream fis = new FileInputStream(archive);
ZipInputStream zis = new ZipInputStream(new BufferedInputStream(fis));
ZipEntry entry;
File destFile;
while ((entry = zis.getNextEntry()) != null) {
destFile = FilesystemUtils.combineFileNames(destinationDir, entry.getName());
if (entry.isDirectory()) {
destFile.mkdirs();
continue;
} else {
int count;
byte data[] = new byte[BUFFER_SIZE];
destFile.getParentFile().mkdirs();
FileOutputStream fos = new FileOutputStream(destFile);
dest = new BufferedOutputStream(fos, BUFFER_SIZE);
while ((count = zis.read(data, 0, BUFFER_SIZE)) != -1) {
dest.write(data, 0, count);
}
dest.flush();
dest.close();
fos.close();
}
}
zis.close();
fis.close();
}
I was getting exception
java.util.zip.ZipException: invalid entry CRC (expected 0x0 but got 0xdeadface)
at java.util.zip.ZipInputStream.read(ZipInputStream.java:221)
at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:140)
at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:118)
...
when unzipping an archive in Java. The archive itself didn't seem corrupted as 7zip (and others) opened it without any problems or complaints about invalid CRC.
I switched to Apache Commons Compress for reading the zip-entries and that resolved the problem.
In my case , my -Dloader.path="lib" contains other jars that doesn't need.
for example,mvn dependency:copy-dependencies lists 100 jar files.but my lib directory contains 101 jar files.
I faced the same problem. I had a zip archive which java.util.zip.ZipFile was not able to handle but WinRar unpacked it just fine. I found article on SDN about compressing and decompressing options in Java. I slightly modified one of example codes to produce method which was finally capable of handling the archive. Trick is in using ZipInputStream instead of ZipFile and in sequential reading of zip archive. This method is also capable of handling empty zip archive. I believe you can adjust the method to suit your needs as all zip classes have equivalent subclasses for .jar archives.
public void unzipFileIntoDirectory(File archive, File destinationDir)
throws Exception {
final int BUFFER_SIZE = 1024;
BufferedOutputStream dest = null;
FileInputStream fis = new FileInputStream(archive);
ZipInputStream zis = new ZipInputStream(new BufferedInputStream(fis));
ZipEntry entry;
File destFile;
while ((entry = zis.getNextEntry()) != null) {
destFile = FilesystemUtils.combineFileNames(destinationDir, entry.getName());
if (entry.isDirectory()) {
destFile.mkdirs();
continue;
} else {
int count;
byte data[] = new byte[BUFFER_SIZE];
destFile.getParentFile().mkdirs();
FileOutputStream fos = new FileOutputStream(destFile);
dest = new BufferedOutputStream(fos, BUFFER_SIZE);
while ((count = zis.read(data, 0, BUFFER_SIZE)) != -1) {
dest.write(data, 0, count);
}
dest.flush();
dest.close();
fos.close();
}
}
zis.close();
fis.close();
}
I've seen this exception before when whatever the JVM considers to be a temp directory is not accessible due to not being there or not having permission to write.
Liquibase was getting this error for me. I resolved this after I debugged and watched liquibase try to load the libraries and found that it was erroring on the manifest files for commons-codec-1.6.jar. Essentially, there is either a corrupt zip file somewhere in your path or there is a incompatible version being used. When I did an explore on Maven repository for this library, I found there were newer versions and added the newer version to the pom.xml. I was able to proceed at this point.
I've seen this exception before when whatever the JVM considers to be a temp directory is not accessible due to not being there or not having permission to write.
Liquibase was getting this error for me. I resolved this after I debugged and watched liquibase try to load the libraries and found that it was erroring on the manifest files for commons-codec-1.6.jar. Essentially, there is either a corrupt zip file somewhere in your path or there is a incompatible version being used. When I did an explore on Maven repository for this library, I found there were newer versions and added the newer version to the pom.xml. I was able to proceed at this point.
I saw this with a specific Zip-file with Java 6, but it went away when I upgrade to Java 8 (did not test Java 7), so it seems newer versions of ZipFile in Java support more compression algorithms and thus can read files which fail with earlier versions.
I solved this by clearing the jboss-x.y.z/server[config]/tmp and jboss-x.y.z/server/[config]/work directories.
On Windows7 I had this problem over a Samba network connection for a Java8 Jar File >80 MBytes big. Copying the file to a local drive fixed the issue.
It could be related to log4j.
Do you have log4j.jar file in the websphere java classpath (as defined in the startup file) as well as the application classpath ?
If you do make sure that the log4j.jar file is in the java classpath and that it is NOT in the web-inf/lib directory of your webapp.
It can also be related with the ant version (may be not your case, but I do put it here for reference):
You have a .class file in your class path (i.e. not a directory or a .jar file). Starting with ant 1.6, ant will open the files in the classpath checking for manifest entries. This attempted opening will fail with the error "java.util.zip.ZipException"
The problem does not exist with ant 1.5 as it does not try to open the files. - so make sure that your classpath's do not contain .class files.
On a side note, did you consider having separate jars ?
You could in the manifest of your main jar, refer to the other jars with this attribute:
Class-Path: one.jar two.jar three.jar
Then, place all of your jars in the same folder.
Again, may be not valid for your case, but still there for reference.
In my case , my -Dloader.path="lib" contains other jars that doesn't need.
for example,mvn dependency:copy-dependencies lists 100 jar files.but my lib directory contains 101 jar files.
Make sure your jar file is not corrupted. If it's corrupted or not able to unzip, this error will occur.
On Windows7 I had this problem over a Samba network connection for a Java8 Jar File >80 MBytes big. Copying the file to a local drive fixed the issue.
I was getting exception
java.util.zip.ZipException: invalid entry CRC (expected 0x0 but got 0xdeadface)
at java.util.zip.ZipInputStream.read(ZipInputStream.java:221)
at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:140)
at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:118)
...
when unzipping an archive in Java. The archive itself didn't seem corrupted as 7zip (and others) opened it without any problems or complaints about invalid CRC.
I switched to Apache Commons Compress for reading the zip-entries and that resolved the problem.
I saw this with a specific Zip-file with Java 6, but it went away when I upgrade to Java 8 (did not test Java 7), so it seems newer versions of ZipFile in Java support more compression algorithms and thus can read files which fail with earlier versions.
Simply to overcome the ZipException's, i have used a wrapper for commons-compress1.14 called jarchivelibwritten by thrau that makes it easy to extract or compress from and into File objects.
Example:
public static void main(String[] args) {
String zipfilePath =
"E:/Selenium_Server/geckodriver-v0.19.0-linux64.tar.gz";
//"E:/Selenium_Server/geckodriver-v0.19.0-win32.zip";
String outdir = "E:/Selenium_Server/";
exratctFileList(zipfilePath, outdir );
}
public void exratctFileList( String zipfilePath, String outdir ) throws IOException {
File archive = new File( zipfilePath );
File destinationDir = new File( outdir );
Archiver archiver = null;
if( zipfilePath.endsWith(".zip") ) {
archiver = ArchiverFactory.createArchiver( ArchiveFormat.ZIP );
} else if ( zipfilePath.endsWith(".tar.gz") ) {
archiver = ArchiverFactory.createArchiver( ArchiveFormat.TAR, CompressionType.GZIP );
}
archiver.extract(archive, destinationDir);
ArchiveStream stream = archiver.stream( archive );
ArchiveEntry entry;
while( (entry = stream.getNextEntry()) != null ) {
String entryName = entry.getName();
System.out.println("Entery Name : "+ entryName );
}
stream.close();
}
Maven dependency « You can download the jars from the Sonatype Maven Repository at org/rauschig/jarchivelib/.
<dependency>
<groupId>org.rauschig</groupId>
<artifactId>jarchivelib</artifactId>
<version>0.7.1</version>
</dependency>
@see
It could be related to log4j.
Do you have log4j.jar file in the websphere java classpath (as defined in the startup file) as well as the application classpath ?
If you do make sure that the log4j.jar file is in the java classpath and that it is NOT in the web-inf/lib directory of your webapp.
It can also be related with the ant version (may be not your case, but I do put it here for reference):
You have a .class file in your class path (i.e. not a directory or a .jar file). Starting with ant 1.6, ant will open the files in the classpath checking for manifest entries. This attempted opening will fail with the error "java.util.zip.ZipException"
The problem does not exist with ant 1.5 as it does not try to open the files. - so make sure that your classpath's do not contain .class files.
On a side note, did you consider having separate jars ?
You could in the manifest of your main jar, refer to the other jars with this attribute:
Class-Path: one.jar two.jar three.jar
Then, place all of your jars in the same folder.
Again, may be not valid for your case, but still there for reference.
Source: Stackoverflow.com