Re: saving files in webapp folder from deletion?
Hello, Pham Tran Quoc Viet wrote: Create x outside of webapps and create a soft link within webapps that points to x. Then, within server.xml add the following lines: Context docBase=absolute path to x soft link path=link name allowLinking=true/ That's it. Everytime the soft link is hit, tomcat will follow the symbolic link get the appropriate requested file under x. Ok, but the tomcat 5 docs say that allowLinking should not be set to true on Windows systems. Although I'm actually using a Unix flavour as a production environment, this would pose problems for our development environments which are Windows-based. Apart from that, I dislike platform-specific solutions. Apart from that, wouldn't the symlinks be deleted when the webapp is undeployed by tomcat? And I couldn't put them into the war file to reappear after re-deployment, could I? -- ___ | | | knipp | Knipp Medien und Kommunikation GmbH --- Technologiepark Martin-Schmeisser-Weg 9 D-44227 Dortmund Dipl.-Inform. Thomas CorteFon: +49-231-9703-0 [EMAIL PROTECTED] Fax: +49-231-9703-200 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: saving files in webapp folder from deletion?
Hello, Anto Paul wrote: Read this thread lately. May be antiResourceLocking is what you are lokking for. I'm afraid not, since it is only useful to prevent files from being locked (to make sure they can be deleted on undeploy). Actually, I'm somewhat looking for the exact opposite, namely a way to *prevent* files in the web app folder from being deleted :-) Since I don't like multi-context solutions, I'll probably have to go for my initial idea of backup on undeploy and restore on deploy. -- Thomas Corte [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: saving files in webapp folder from deletion?
Hi, Leon Rosenberg wrote: I think in the time you invested in this thread you could easily have written a servlet which delivers the data from anywhere, so you don't need to save it in the context. You are absolutely right, however I don't like to reinvent the wheel and therefore tend to look for existing solutions before introducing my own. Besides, due to the fact that the uploaded stuff represents the entire static content of the site, I have to be careful not to introduce performance penalties or security issues (e.g. by ../../... accesses). I'd also have to mimic Tomcats extension-to-mimetype mechanisms and other stuff, something that I'd like to circumvent. But maybe I'll go for such as servlet. Regards, -- Thomas Corte [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
saving files in webapp folder from deletion?
Hi there, I have a setup in which certain trusted users of a web application X may upload new content files which are then put into webapps/X/content to be served from there. The problem is that everything unter /webapps/X is *deleted* by Tomcat upon undeploy, including the uploaded stuff. My question is: what would be the best way to deal with this? Of course, I'd love to put the uploaded files into directories *outside* of webapps/X, but there seems to be no way to let Tomcat serve them then as part of webapp X. A possibility I'm currently considering is to backup the files by an Application Listener prior the the undeployment and to restore them upon re-deploy. Any thoughts? -- Thomas Corte [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: saving files in webapp folder from deletion?
Hi, Leon Rosenberg wrote: setup X as context/webapp (incl. an empty WEB-INF) and probably a web.xml. this should be sufficent, unless you have something else badly broken :-) So you mean I should create a second web app/context Y and put the uploaded files there? If this is the suggestion, it would create new problems: - The upload code in X would have to use absolute paths to point to directories within the reach of Y. - I didn't mention it before, but access to parts of the uploaded content, as well as to the upload form itself, must be restricted by a sign-on process implemented in webapp X. However, if the content is served by another webapp Y, this would prove difficult since there is no session sharing across webapps, is there? -- Thomas Corte [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No Host matches server name localhost error
Hello, Parsons Technical Services wrote: Now as for the issue, I am not sure that it is a bug but just a feature. Unless you can show where it does not meet the servlet specs then it will not be considered a bug. Ok, and since the issue is actually documented, it cannot be called a bug. Understood; no offense intended :-) I am not sure why this is causing such a problem. The only time a default context will ever be used is if the browser is using an IP instead of a URL or if you have a DNS entry that points to your IP with no matching application. So unless you are using only the IP or are directing multiple unmatched URLs at the server there is no issue. If you are, then knowing what the war is about is only a small piece of the puzzle that exist in the setup. I may really be missing something here, but my impression was that a host's default web application is used whenever a URL is requested that does not match any other context's path prefix within the host - regardless of the access being made by IP address or by domain name. To me, this means that I *need* a default context if I want to see the welcome page of my foo web application (within the host named www.foodomain.com) at http://www.foodomain.com; and not at http://www.foodomain.com/foo;, right? If this is right, then I'd have to tamper with server.xml or name my .war file ROOT.war. I can live with the latter, but it feels somewhat unclean. IMO, the same applies to setting up a minimal ROOT.war that simply forwards to another context, since this will also cause an unnecessary /foo prefix in every subsequent request URL. -- Thomas Corte [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No Host matches server name localhost error
Hi, Parsons Technical Services wrote: Per the 5.5 doc you can't do it that way. You can only specify the path as a blank string when the context element is in the server.xml. To reiterate: so the only 2 ways to define the *default web app* for the host are either - to define the context in server.xml (which is inconvenient because it may e.g. contain JNDI resource definitions that have to be updated whenever META-INF/context.xml within the war changes) or - to name the war file for the default webapp ROOT.war (which is somewhat crappy, too, since it e.g. leaves no hint at what the war is about if someone just looks at the webapps drawer) If the above is true, I wonder why the path attribute of the context defined in META-INF/context.xml isn't simply considered in *any* case? Shouldn't this be considered a tomcat bug? -- Thomas Corte [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
adding new virtual hosts without restart?
Hello, I understand that it is possible to (re-)deploy new contexts/web applications in Tomcat 5.5.9 without a complete server restart. I wonder whether the same might be possible for new virtual hosts, i.e. adding new virtual hosts/IP addresses to a running Tomcat server. From the documentation, I get the impression that this is *not* possible, which means that I'd have to stop and start tomcat to do this. Is there a way to do it without restart? -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
