java.util.zip.ZipException: erreur lors de l'ouverture du fichier zip

Question

J'ai un fichier Jar qui contient d'autres imbriqués les Pots. Quand j'invoque le nouveau Jarfiles() constructeur, sur ce fichier, j'obtiens une exception qui dit "java.util.zip.ZipException: erreur dans l'ouverture de fichier zip". Quand j'ai manuellement décompressez le contenu de ce fichier Jar et zip il de nouveau, il fonctionne très bien. Aussi, veuillez noter que cette exception n'est perçue que sur websphere 6.1.0.7 et les versions supérieures. La même chose fonctionne bien sur tomcat et weblogic. Aussi, lorsque j'utilise JarInputStream au lieu de Jarfiles, je suis capable de lire le contenu du fichier Jar, sans aucune exception. S'il vous plaît laissez-moi savoir si vous avez des idées sur la façon dont cela peut être corrigé.

Merci, Sandhya

Answer 1

assurez-vous que votre fichier jar n'est pas corrompu .. s'il est corrompu ou incapable de décompresser cette erreur se produira ..

Answer 2

J'ai connu le même problème. J'ai eu une archive zip qui java.util.zip.ZipFile n'a pas été en mesure de gérer mais WinRar déballé juste fine. J'ai trouvé l'article sur la SDN a propos de la compression et de la décompression d'options en Java. J'ai légèrement modifié l'un des exemple les codes pour produire de la méthode qui a enfin capable de gérer les archives. Astuce consiste à utiliser ZipInputStream au lieu de ZipFile et dans la lecture séquentielle d'archive zip. Cette méthode est aussi capable de gérer vide archive zip. Je crois que vous pouvez adapter la méthode en fonction de vos besoins comme tous les colliers de classes d'équivalence sous-classes pour .archives jar.

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();                        
    }

Answer 3

J'ai déjà vu cette exception lorsque tout ce que la machine virtuelle Java considère comme un répertoire temporaire n'est pas accessible car il n'existe pas ou n'est pas autorisé à écrire.

Answer 4

Il pourrait être lié à log4j.

Avez-vous des log4j.jar fichier dans le chemin de classe java websphere (tel que défini dans le fichier de démarrage) ainsi que l'application classpath ?

Si vous assurez-vous que la log4j.jar le fichier est dans le chemin de classe java et qu'il n'est PAS dans le web-inf/lib de votre webapp.

---

Il peut également être liée avec la fourmi version (peut-être pas votre cas, mais je ne le mets ici pour référence):

Vous avez une .classe de fichier dans votre chemin de classe (c'est à dire pas un répertoire ou un .fichier jar). En commençant par ant 1.6, fourmi va ouvrir les fichiers dans le classpath de vérification pour les entrées du manifeste. Cette tentative de l'ouverture échoue avec l'erreur "java.util.zip.ZipException"

Le problème n'existe pas avec ant 1.5 comme il n'essayez pas d'ouvrir les fichiers. - donc, assurez-sûr que votre classpath ne contiennent pas .les fichiers de classe.

---

Sur une note de côté, avez-vous envisager d'avoir des pots séparés ?
Vous pourriez dans le manifeste du pot, reportez-vous à l'autre des bocaux avec cet attribut:

Class-Path: one.jar two.jar three.jar

Ensuite, placez tous vos bocaux dans le même dossier.
Encore une fois, peut ne pas être valide pour votre cas, mais toujours là pour référence.

Answer 5

J'ai résolu ce problème en effaçant les répertoires jboss-xyz / server [config] / tmp et jboss-xyz / server / [config] / work.