-
1. Re: jzentry == 0
mroli Aug 30, 2002 2:41 PM (in response to cconnelly)I second this... I *always* get this crash if I change a jar file in my web-inf/lib directory. A estart is required to fix it.
Most annoying.
Chris -
2. Re: jzentry == 0
jules Aug 30, 2002 8:49 PM (in response to cconnelly)See the FAQ I posted yesterday in this forum.
You are probably copying a large file across a slow network.
Jules -
3. Re: jzentry == 0
cconnelly Sep 3, 2002 12:23 PM (in response to cconnelly)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. -
4. Re: jzentry == 0
jules Sep 3, 2002 2:47 PM (in response to cconnelly)Maybe Jetty is just SO FAST that it gets to the end of the file before you have finished copying it in. :-)
If the problem is caused, as I suspect, then it will affect any JBoss deployable, because it is JBoss which decides when deployment begins.
Try doing as I suggest. If the problem disappears, then this is most likely the cause and perhaps Tomcat is just slower at deploying, or your Tomcat setup impacts in some way on the problem.
If my suggestion does not resolve your problem, come back to the list with a piece of your log and a stacktrace and I will see what I can do.
Jules -
5. Re: jzentry == 0
cconnelly Sep 3, 2002 5:39 PM (in response to cconnelly)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 -
6. Re: jzentry == 0
cconnelly Sep 17, 2002 2:09 PM (in response to cconnelly)Hey Jules, do you have an update for me on this?
-
7. Re: jzentry == 0
jules_gosnell Sep 17, 2002 7:33 PM (in response to cconnelly)send me :
a war that displays this problem.
jvm version
os version
anything else relevant.
I will try to duplicate it.
Jules -
8. Re: jzentry == 0
adrian.brock Sep 18, 2002 2:15 PM (in response to cconnelly)Hi Jules,
I can reproduce this, but I'm not sure sending you
a war is relevent. I actually saw it last week
when playing with the skeleton project for
webworks.
You have to change a support jar in WEB-INF/lib
before redeploying.
Just redeploying the same war works ok.
The problem is only in the 3.0 branch,
when I switched to 3.2 it didn't happen.
Regards,
Adrian -
9. Re: jzentry == 0
cconnelly Sep 18, 2002 3:56 PM (in response to cconnelly)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). -
10. Re: jzentry == 0
cconnelly Sep 18, 2002 4:06 PM (in response to cconnelly)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.
-
11. Re: jzentry == 0
jules Sep 20, 2002 6:44 AM (in response to cconnelly)OK - we're looing at it.
Jules -
12. Re: jzentry == 0
jules Sep 21, 2002 7:36 AM (in response to cconnelly)Greg think that he has found the cuase of this.
It looks like the Jboss deployer is not doing a very good job of cleaning up old deployments. Tomcat makes no effort to reuse the old unpacking directory, Jetty does - hence the problem.
Jetty is now a lot more careful about what it tries to reuse.
There should be a 4.1.0RC7 release by the end of the day. Download it and try substituting the *mortbay*.jars from it into your /deploy/jbossweb.sar. Depending on whether you are using 1.2/3 or 1.4 you will need to select the correct org.mortbay.jetty.jar.
Let me know if this resolves your problem, So I can close the bug.
Thanks for your patience - we're a bit overloaded at the moment,
Jules -
13. Re: jzentry == 0
jules Sep 21, 2002 7:38 AM (in response to cconnelly)Greg think that he has found the cuase of this.
It looks like the Jboss deployer is not doing a very good job of cleaning up old deployments. Tomcat makes no effort to reuse the old unpacking directory, Jetty does - hence the problem.
Jetty is now a lot more careful about what it tries to reuse.
There should be a 4.1.0RC7 release by the end of the day.
http://sourceforge.net/project/showfiles.php?group_id=7322
Download it and try substituting the *mortbay*.jars from it into your /deploy/jbossweb.sar. Depending on whether you are using 1.2/3 or 1.4 you will need to select the correct org.mortbay.jetty.jar.
Let me know if this resolves your problem, So I can close the bug.
Thanks for your patience - we're a bit overloaded at the moment,
Jules -
14. Re: jzentry == 0
jules Sep 23, 2002 5:19 AM (in response to cconnelly)RC7 is turning into 4.1.0. This should be out within the next couple of days.
Thanks for your patience.
Jules