That bug refers to a ROOT.war that NEVER correctly unpacks (so it's repeatable), and although it doesn't say explicitly, I think the WAR unpacks completely, but the webapp isn't initialized properly because Tomcat doesn't like the context declaration.
My WAR contains no context.xml -- it is just named ROOT.war, and expects to be deployed in the root context based on Tomcat's special ROOT handling. I've got my script running in an attempt to reproduce the unpack failure, and I think I'm going to leave it running over the weekend. -----Original Message----- From: Johnny Kewl [mailto:[EMAIL PROTECTED] Sent: Friday, May 11, 2007 1:13 PM To: Tomcat Users List Subject: Re: WAR deployment incomplete (sometimes) HEY! wots this..... ROOT.war does not unpack http://issues.apache.org/bugzilla/show_bug.cgi?id=36887 Its a reported bug?????? ----- Original Message ----- From: "Michael Heinrichs" <[EMAIL PROTECTED]> To: "Tomcat Users List" <users@tomcat.apache.org> Sent: Friday, May 11, 2007 3:17 PM Subject: RE: WAR deployment incomplete (sometimes) The WAR file is being generated by the Ant WAR task (Ant 1.6.5). I'm don't want to rule anything out, but if the WAR file is bad, I would expect the deployment to fail every time, or when it does fail, always fail at the same point in the WAR expansion. -----Original Message----- From: Johnny Kewl [mailto:[EMAIL PROTECTED] Sent: Friday, May 11, 2007 4:46 AM To: Tomcat Users List Subject: Re: WAR deployment incomplete (sometimes) Hi Michael... shame still struggling with this. One thing you not telling us is wot is packaging the WAR. A WAR is basically a zip... but I do know that if you zip using external programs like AlZip or WinZip... the Java zip api can struggle with that. Also if you using netbeans right click on the project and have a look if its using compression... take that off and then its plain... bigger... but plain.. anything should open that file. Super Compression is a recent addition to Java.... maybe the jre u using is just when it was introduced.... ie the dev environment is higher version than the runtime env. I dont think 23mb should be any problem for a zip... ----- Original Message ----- From: "Michael Heinrichs" <[EMAIL PROTECTED]> To: "Tomcat Users List" <users@tomcat.apache.org> Sent: Thursday, May 10, 2007 9:33 PM Subject: RE: WAR deployment incomplete (sometimes) Thanks for your comments, I have a collected a second data point, which shows that the WAR does not stop unpacking at the same point every time. The first recorded incident was on Solaris, and this second incident was on Windows. Again, there was no exception or error message in the Tomcat logs. The WAR file contains 1461 entries (~23MB). Solaris stopped after 797 entries. Windows stopped after 1326 entries. I doubt future incidents on the same platforms will stop at the same points. I've searched the Sun Java bug database, and found lots of interesting JRE JAR/WAR/zip bugs, triggered by such things as JARs larger than 2GB (large file support), and JARs with more than 64,000 entries, but none of the bugs apply to my situation. -----Original Message----- From: Michael Heinrichs [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 09, 2007 10:43 AM To: users@tomcat.apache.org Subject: WAR deployment incomplete (sometimes) Hello everyone, I am having a problem with WAR deployment. I am performing a static deployment: copying a ROOT.war under the webapps directory, and then starting Tomcat (no other web applications). On most occasions, the deployment is successful. However, occasionally the deployment does not succeed, and the WAR is only partially unpacked. Subsequently stopping Tomcat, deleting the expanded webapp directory, and starting Tomcat again will (normally) result in a successful deployment. When this happens, I see no exceptions in the logs. I've looked at the Tomcat source responsible for WAR expansion, and found no clues. I have begun collecting data to establish whether the unpacking always stops at the same point in the WAR, but only have one data point so far. I have verified that the WAR unpacking stops at a sequential point (all files before that point are unpacked, and all files after that point have not been unpacked). In the single instance I have recorded, unpacking stops between two similar, and unremarkable HTML files. This problem has occurred on Solaris, Linux (Redhat), and Windows, so this problem is not platform-specific. I've searched the mailing list archives, and I can find no reference to others having the same problem. Can anyone offer an explanation or solution? Thanks, Mike --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
