Hi, He did ask in this area, but that's not the answer he wants. 1. No, the Servlet Spec does not provide a means to control packing or unpacking of WARs. This is a container-specific feature that's not even required by the spec (only running packed WARs is required).
2. There is no portable persistent space to store things like uploaded files. The javax.servlet.context.tempdir is for temporary things and may be wiped out by the server when it restarts. The reason these things aren't there goes to the roots of the J2EE philosophy, and the role of the Application Deployer. This person is responsible for configuring (ideally via JNDI) those environment needs of your app that you declare in your web.xml. See the Servlet Spec explanation of the env-entry/env-entry-ref elements. Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: rlipi [mailto:[EMAIL PROTECTED] >Sent: Tuesday, May 18, 2004 9:37 AM >To: 'Tomcat Users List' >Subject: RE: Persistent workspace > >Hi, >see this: > > <Host name="localhost" debug="0" appBase="webapps" > unpackWARs="true" autoDeploy="true" > xmlValidation="false" xmlNamespaceAware="false"> > >There is unpackWARs attribute in the Host element in the server.xml. > >But I'm not sure that you have asked about this. > >Lipi > > >> -----Original Message----- >> From: Simon Brooke [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, May 18, 2004 3:17 PM >> To: Tomcat Users List >> Subject: Persistent workspace >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> I've been deploying webapps with Tomcat since 1997, so you'd think I >> should >> know what I'm doing by now... >> >> But I find I don't. I'm increasingly trying to package my webapps so >that >> they >> can be 'just dropped in' without any skill or knowledge being needed >by >> the >> site administrator to get them set up and deployed, and this has >raised >> two >> problems with relation to persistent workspace. >> >> If a preconfigured war file is installed into Tomcat using the manager >> webapp, >> it doesn't get unpacked, and in many ways that's a good thing. But I >have >> up >> till now used sub-directories of the webapp root directory to store >> persistent data, for example cached pages and uploaded files. More >> particularly, I've been using the presence of a file >'WEB-INF/hymen.txt' >> as a >> marker that this webapp has never been accessed before and needs final >> initialisation, and had any servlet redirect to a special servlet >which >> handled final setup if that file exists. Obviously, the final setup >> servlet >> then removed the marker file. Clearly neither of these things work if >the >> webapp is delivered as a war file. >> >> Generally my webapps talk to databases (usually SQL databases, but >could >> be >> LDAP, or other things) so it should be possible to replace the >'hymen.txt' >> mechanism with a simple database call which will succeed if the >database >> has >> been initialised but fail if it hasn't. >> >> However this doesn't solve the problem of where to put caches and >upload >> directories, and I can't find anything in the Servlet API which helps >with >> this. I really don't want to be storing large lumps of arbitrary data >into >> the database. >> >> Is there any mechanism in the Servlet spec which allows me either >> (i) to request that my war file should be unpacked when it is >deployed, or >> else >> (ii) to get hold of some persistent filespace that my webapp can write >to? >> >> Cheers >> >> Simon >> >> - -- >> [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ >> ;; Our modern industrial economy takes a mountain covered with >> trees, >> ;; lakes, running streams and transforms it into a mountain of >junk, >> ;; garbage, slime pits, and debris. -- Edward >> Abbey >> >> -----BEGIN PGP SIGNATURE----- >> Version: 2.6.3ia >> Charset: noconv >> >> iQCVAwUBQKoM4nr1UrYJMbiJAQHbngP/SGMuawDkFhjStVUZUka8wjhPy+0yM+k/ >> Fm6v8niMFNyxGLvRhBkQEt7Wd8ZLrfIMKmssIiivuHZkf0ErYyc/hfRBmizG8xCG >> j3fc2KtvoRp1L2+sH+UyfJwW8lWQHDNFF+kc9MXTXKfs3nTFMBUtvjmVx6tI6fYe >> fOc3H1eikjE= >> =lAMw >> -----END PGP SIGNATURE----- >> >> >> --------------------------------------------------------------------- >> 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]
