JBoss5: Cannot deploy due to java.util.zip.ZipException: error in opening zip file

Question

I have a web client and a EJB project, which I created with Eclipse 3.4. When I want to deploy it on Jboss 5.0.1, I receive the error below. I searched a lot but I wasn\'t a

Answer 1

The problem is most likely in the low level format of the ZIP file, possibly the result of JBoss trying to deploy a partially uploaded archive,

Caused by: 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:203)
    at java.util.zip.ZipFile.<init>(ZipFile.java:234

If you are uploading to a server over a slow link then try uploading the archive to a directory that JBoss does not monitor then move the archive into the deploy directory. The move will be an atomic operation or at least a lot faster than the upload.

I deploy archives by rsync'ing to ~/deployment-unit/ and then running a remote script over ssh to do the final move into JBoss's deployment directory.

Answer 2

I had the same problem, mine solution/problem was that I added the jar that was causing the problem as a EE dependency in my EJB. The jar was included in the EAR file, but wasn't in the org.eclipse.wst.common.component correspondent file. I added the dependency in the EAR file, and my problem was solved (At least I think, I had a problem after doing this with eclipse, but when I solve it, the publish went fine).

Answer 3

Had the same problem, using JBoss 4.4.2 and building my app with maven-war-plugin (specifyng as outputDirectory the JBoss deploy dir). It seems that JBoss tries to reload a partially copied war, because its ScannerThread activates while maven is still building the war. I partially resolved increasing the scan time from 5000 msec (the default) to 15 secs. This does not solve the problem, but at least it happens less frequently!

   <!-- Frequency in milliseconds to rescan the URLs for changes -->
  <attribute name="ScanPeriod">15000</attribute>

Answer 4

May be its your web.xml file problem, i'm also face same kind of issue, After a lot of different tries, I was about to go down the road discussed another article about the web.xml and web-app 3.0. This got me to thinking and I checked out my web.xml. Sure enough, the following line was right there at the top.

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">

I changed over to a 2.5 web-app spec. Both the WAR and EAR would not deploy.

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">

Answer 5

I added below mentioned code in web.xml under yourServletName and the error got removed

<servlet-name>youServletName</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
 **<init-param>
  <param-name>contextClass</param-name>
  <param-value>org.jboss.spring.vfs.context.VFSXmlWebApplicationContext</param-value>
</init-param> 
<load-on-startup>2</load-on-startup>**
</servlet>

Answer 6

I had the same problem on my Mac. My windows dev machine (client at work :-/) is too slow to run GateIN and eclipse so I installed GateIN on my Macbooc Pro and let eclipse copy the ear to it when built. I saw on the console: exception in the zip.

So I decided to investigate if I could perhaps open the archive using Stuffit Manager. The moment I opened it, apparently the file got 'touched' somehow and the GateIN scanner, detecting the change immediately redeployed, this time without error. So I guess that the Mac was simply too fast to try to redeploy before the ear was fully copied... If you have a problem, just use the touch command...