I read the following entry from the the FAQ:

"Sometimes when I copy apps into .../deploy/ I get "invalid LOC header" errors
-----------------------------------------------------------------------------

This is because JBoss started to read and deploy the file before the
copy had finished. For 100% safe deployment, copy your file to a
teporary space on the same filesystem as the deploy dir, then
move/rename it into the deploy dir. This will be an atomic operation
for your filesystem, so JBoss will see the whole file appear in one
go, not a file gradually increasing in size. Alternatively, you can
use the JMX interface to pass the url of the app that you want
deployed - see JBoss doc."

This all makes sense, but I do not understand why this only happens when I am using Jetty and never seems to happen when I use tomcat as my container. It seems like this is a bug with Jetty and it can be fixed.

I changed my code to do a move rather than a copy and I just got the same problem again. Here is the stack trace:

2002-09-03 16:43:17,360 ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] Failed to deploy: org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@21ffcb3{ url=file:/C:/jboss-3.0.2/server/default/deploy/manager-cactus.ear, deployedLastModified=0 }
org.jboss.deployment.DeploymentException: Could not create deployment: file:/C:/jboss-3.0.2/server/default/tmp/deploy/server/default/deploy/manager-cactus.ear/66.manager-cactus.ear-contents/cm-cactus.war; - nested throwable: (java.lang.InternalError: jzentry == 0,
jzfile = 191786944,
total = 223,
name = C:\Documents and Settings\cconnelly\Local Settings\Temp\Jetty__8080___cm-cactus\webapp\WEB-INF\lib\config-interfaces.jar,
i = 44,
message = invalid LOC header (bad signature))
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:822)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:794)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:616)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy4.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:427)
at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymentScanner.java:648)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:499)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:212)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:225)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:202)
Caused by: java.lang.InternalError: jzentry == 0,
jzfile = 191786944,
total = 223,
name = C:\Documents and Settings\cconnelly\Local Settings\Temp\Jetty__8080___cm-cactus\webapp\WEB-INF\lib\config-interfaces.jar,
i = 44,
message = invalid LOC header (bad signature)
at java.util.zip.ZipFile$2.nextElement(ZipFile.java:303)
at java.util.jar.JarFile$1.nextElement(JarFile.java:200)
at org.apache.jasper.compiler.TldLocationsCache.tldConfigJar(TldLocationsCache.java:238)
at org.apache.jasper.compiler.TldLocationsCache.processJars(TldLocationsCache.java:211)
at org.apache.jasper.compiler.TldLocationsCache.(TldLocationsCache.java:139)
at org.apache.jasper.EmbededServletOptions.(EmbededServletOptions.java:350)
at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:265)
at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:208)
at org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:427)
at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:405)
at org.jboss.jetty.Jetty.deploy(Jetty.java:409)
at org.jboss.jetty.JettyService.performDeploy(JettyService.java:243)
at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:300)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:802)
... 16 more

Hey Jules, do you have an update for me on this?

Jules,

Unfortunately it doesn't seem like this bug can be reproduced by a simple ear file. It seems to have something to do with continually redeploying a file with the same name whose contents have changed slightly.

Basically the bug never happens when I redeploy the same exact file over again. It only happens during the development testing process. Where an archive is deployed to JBoss, tested, changed, redeployed and tested again. Which leads me to believe that this is some sort of cache confict issue.

If it helps: I am running JDK 1.4 on Windows XP (though I have seen this problem with JDK 1.3 as well).

The ear file I typically deploy contains a struts based war file, and ejb-jar that is using CMP and relations. I communicate between the war and the ejb-jar using an interfaces jar file in the lib of the war file (the "config-interfaces.jar" that showed up in the above trace message).

After reading the post by Adrian it makes sense why I continue to get this problem. Every time I run my deploy procedure I rebuild the "config-interfaces.jar" which lives in the war's lib directory. When there are changes in that file this most likely causes the loader to choke. Good to hear it might be fixed in 3.2.