Thanks everyone for the info. If there are any developers on the list...almost every other app server will expand a war over the top of an existing deployment (9iAS, Orion, WebSphere, etc I know of for sure). It would be a very useful feature to have.
The files the users upload in my app, get used in the interface of my jsp-like pages so they can't be placed outside of the docBase. I think I will need to copy all these files out, delete the deployment, then copy them back every time I need to deploy. Not perfect, but it will work. --Dan -----Original Message----- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 8:23 AM To: Tomcat Users List Subject: RE: problem redeploying war files on tomcat 4.x Hi, If you tell the server to unpack your WAR, it does, but then it won't remove the unpacked directory because you (or your web designers) may have updated stuff in it. So you have to "manually" remove this unpacked directory. If you keep the WAR packed then you don't need to worry about this and can just deploy a new WAR. In your scenario, a few thoughts come to mind: - You could define a directory for uploads that is outside your docBase, and write the things users upload there. That way you can keep your WAR packed. - You could write the uploaded things into a database, rather than the filesystem (whether it's a BLOB, CLOB, LONG RAW, or whatever depends on your database and your requirements). - If the "things" they upload need only stay around for the duration of the application, and need not survive a server restart, you can write them to your context's tempdir. Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: Wick, Daniel [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 06, 2004 9:13 AM >To: 'Tomcat Users List' >Subject: RE: problem redeploying war files on tomcat 4.x > >Thanks Yoav. Well, inside the application, users upload things into the >application directories. That's why I have to expand the war...and also >don't want to delete every time we deploy. Is this possible to do? We >currently use 9iAS/Orion...which does this - but now we're switching to >Tomcat & I'm not as familiar with deployments. > >--Dan >-----Original Message----- >From: Shapira, Yoav [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 06, 2004 8:05 AM >To: Tomcat Users List >Subject: RE: problem redeploying war files on tomcat 4.x > > > >Hi, >Can you turn off unpackWARs for your Host and run from a packed WAR? > >Yoav Shapira >Millennium Research Informatics > > >>-----Original Message----- >>From: Wick, Daniel [mailto:[EMAIL PROTECTED] >>Sent: Tuesday, October 05, 2004 9:12 PM >>To: '[EMAIL PROTECTED]' >>Subject: problem redeploying war files on tomcat 4.x >> >>Hi. I have an existing application deployed as a war file. When I >update >>the war file, stop and start tomcat again, the war file is not >re-expanding >>over the old deployment. I have set the permissions to 777 so it >should >>not >>be a permissions issue. >> >>It works if I delete the existing directory it expands into, then >restart >>tomcat, however that's not practical for a production environment. >Anyone >>have any ideas for me? >> >>--Dan >> >> >>Supporting configs: >>xml fragment in webapps: >><!-- BEGIN CONTEXT --> >><Context >> path="/bar" >> docBase="/foo/bar.war" >> debug="0" >> reloadable="true" >> crossContext="false" >> privileged="true" >> > >> >></Context> >><!-- END CONTEXT --> >> >>server.xml >> <Host name="foo.com" >> debug="0" appBase="/foo" >> unpackWARs="true" autoDeploy="true" >> deployXML="true" liveDeploy="true"> >> >>The odd thing is that the logs indicate it's writing the files, but >they >>don't actually get updated. >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] > > > > >This e-mail, including any attachments, is a confidential business >communication, and may contain information that is confidential, >proprietary >and/or privileged. This e-mail is intended only for the individual(s) to >whom it is addressed, and may not be saved, copied, printed, disclosed or >used by anyone else. If you are not the(an) intended recipient, please >immediately delete this e-mail from your computer system and notify the >sender. Thank you. > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
