I've noticed on occasion that when I try to copy an updated ear to the deploy directory, that JBoss may attempt to read the ear before the copy completes. I'll get an error like this:
2005-10-29 23:12:37,856 INFO [org.jboss.web.tomcat.tc5.TomcatDeployer] undeploy, ctxPath=/, warUrl=file:/apps/jboss-4.0.2/server/default/tmp/deploy/tmp52483my.ear-contents/my.war/
2005-10-29 23:12:37,985 INFO [org.jboss.deployment.EARDeployer] Undeploying J2EE application, destroy step: file:/apps/jboss-4.0.2/server/default/deploy/my.ear
2005-10-29 23:12:38,071 INFO [org.jboss.deployment.EARDeployer] Init J2EE application: file:/apps/jboss-4.0.2/server/default/deploy/my.ear
2005-10-29 23:12:38,153 WARN [org.jboss.deployment.EARDeployer] Failed to extract nested jar. Ignoring: my.war
java.util.zip.ZipException: invalid stored block lengths
The EAR is about 5MB, so the copy can take a couple seconds. But JBoss/Tomcat's eagerness to hot deploy the ear means that it appears to do so before the copy is complete.
Is there any way to protect against this so that the re-deploy doesn't begin until the copy is complete?
I know this is a bit of a kludge, but copy the EAR into another directory on the same drive. Once the copy is complete, do a 'move' to get the file into the deploy directory.
The file move is almost instantanious because only the file reference is changed.