java.lang.IllegalArgumentException: Ungültige oder unlesbare WAR-Datei: Fehler beim Öffnen der Zip-Datei


Answers

Ich habe den Fehler zufällig gefunden. Ich denke, die Ursache ist ziemlich einfach.

Dies kann passieren, wenn Sie die WAR-Datei erstellen und sie durch einen "langsamen" Prozess in das tomcat-Verzeichnis übertragen. In meinem Fall ist es ein Transfer von einer entfernten Maschine per scp. Der Tomcat kann feststellen, dass die Datei geändert wurde (Änderungsdatum usw.), bevor die Übertragung beendet ist. Es kann dann versuchen, die unvollständige Datei bereitzustellen. Es wird ein Zip-Fehler auftreten.

Das Gleiche kann theoretisch passieren, wenn Sie die Datei aus einem anderen Verzeichnis kopieren; obwohl die Chancen kleiner sind, da die Kopie schneller ist.

Um den Fehler vollständig zu vermeiden, sollte die Datei von einem anderen Speicherort auf demselben Datenträger verschoben (nicht kopiert) werden. Eine solche Bewegung ist (denke ich) atomar.

Während ich mich entwickle, ist das Auftreten des Fehlers von Zeit zu Zeit kein großes Problem; Wenn ich darauf stoße, starte ich die Übertragung einfach neu.

Question


Ich habe diesen Fehler in Catalina.2011-03-30.log, wenn meine Datei display.war auf Tomcat ausgeführt. Der Fehler ist unten gezeigt:

Mar 30, 2011 8:01:31 PM org.apache.catalina.startup.ContextConfig init  
SEVERE: Exception fixing docBase for context [/Display]   
java.util.zip.ZipException: error in opening zip file  

    at java.util.zip.ZipFile.open(Native Method)  
    at java.util.zip.ZipFile.<init>(ZipFile.java:114)
    at java.util.jar.JarFile.<init>(JarFile.java:135)
    at java.util.jar.JarFile.<init>(JarFile.java:72)
    at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:72)
    at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:48)
    at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:70)
    at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
    at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:71)
    at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:148)
    at org.apache.catalina.startup.ContextConfig.fixDocBase(ContextConfig.java:886)
    at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:1021)
    at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:279)
    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
    at org.apache.catalina.core.StandardContext.init(StandardContext.java:5602)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:4378)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546)
    at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:905)
    at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:740)
    at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:500)
    at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1345)
    at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:303)
    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
    at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
    at java.lang.Thread.run(Thread.java:662)  

Mar 30, 2011 8:01:31 PM org.apache.catalina.core.StandardContext resourcesStart
SEVERE: Error starting static Resources  

java.lang.IllegalArgumentException: Invalid or unreadable WAR file : error in opening zip file  
    at org.apache.naming.resources.WARDirContext.setDocBase(WARDirContext.java:135)  
    at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4249)  
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:4418)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546)
    at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:905)
    at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:740)
    at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:500)
    at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1345)
    at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:303)
    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
    at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
    at java.lang.Thread.run(Thread.java:662)  

Danke im Voraus.




Selbes Problem hier. Kriegsdatei kann mit 7-Zip geöffnet werden.

Edit : Ich habe herausgefunden, warum. "Ungültige oder unlesbare WAR-Datei: Fehler beim Öffnen der Zip-Datei" ist definitiv eine verwirrende Fehlermeldung. Der wahre Grund ist einfach "Tomcat kann den Krieg nicht bereitstellen, da es einige Initialisierungsfehler gibt". In meinem Fall fehlen in meiner War-Datei einige Konfigurationsdateien, die die Ausnahme "Datei nicht gefunden" auslöschen. Verschiedene Tomcat-Version scheint verschiedene Fehler zu melden. Unter 6.0.26 meldet es den Fehler korrekt. Aber unter 6.0.32 meldet es die verwirrende "Ungültige oder unlesbare WAR-Datei".




BalusC hat Recht. Dieser Fehler ist aufgetreten, als ich meine Webanwendung auf einer Linux-Box ausgeführt habe, auf der anstelle eines normalen JDK die openjdk-Version von Java installiert war. Nach der Installation eines normalen JDK und dem Zeigen der Tomcat-JRE_HOME-Variable auf das normale JDK verschwand das Problem.




Die Ursache wird deutlich gezeigt:

java.lang.IllegalArgumentException: Invalid or unreadable WAR file : error in opening zip file  

Eine WAR Datei (Web ARchive) ist eine ZIP-Datei, die Ihre Klassen, Bibliotheken und Ressourcen für Ihre Webanwendung enthält.

Benennen Sie Ihre WAR-Datei von a.war in a.zip . Wenn Sie die Zip-Datei nicht mit Winzip / 7-Zip / WinRar öffnen können, bauen Sie Ihre WAR-Datei erneut auf.

Hoffe das hilft.




Ich habe das gleiche Problem viele Male und schließlich fand ich die Lösung .. genaue Lösung sowieso Ich war Tomcat 8.0.9 lokal zum Testen und beim Hochladen der WAR-Datei auf den Server habe ich die Fehlermeldung mit dem Entpacken des Krieges .. so habe ich überprüft Server Tomcat und es war 6, also habe ich diese Version installiert und überprüfte die Version von Java auf dem Server und fand es 5, also stelle ich auch sicher, dass ich Version 5 auf meinem lokalen Rechner benutze. Das Problem tritt auf, wenn die gleiche Datei verwendet wird. Wenn Sie die selbe Version und Tomcat verwenden, wird es korrekt verpackt, so dass der Server ... eine andere Lösung verstehen kann. Aktualisieren Sie die Serverversion, damit sie mit der lokal verwendeten Version übereinstimmt. sie sollten gleich sein. Ich hoffe, dies wird Ihr Problem lösen.




In meinem Fall habe ich WinSCP verwendet, um die Datei zu übertragen. Ich habe viele Male mit allen hier beschriebenen Vorschlägen versucht. Alles, was ich getan habe, um es zum Laufen zu bringen, war, den WinSCP neu zu starten, und der Tomcat konnte die Datei lesen.




In meinem Fall verursachte Dateikorruption während der Dateiübertragung dieses Problem. Daher ist es immer eine bewährte Methode, die Prüfsumme der Datei zu validieren, wenn wir sie auf einen Remote-Server übertragen.