Re: Tomcat won't serve newly created files
One possibility is that you have a ROOT.xml in conf/Catalina/localhost that defines a different docBase for your webapp. Sorry there's no such file defined in that directory path. There is only one version of tomcat on the system. The web.xml is the one I found in the conf folder for tomcat and the login is done programmatically. As for why the context element is missing in it I don't know, but I've never had to touch it either, I'm also only using one AccessLogValve I must've uncommented the other. As for the possibility of proxy caching/firewall issues I'll test for that later but I really doubt that is the issue. (I have emptied the webapp folder and connected to the server. It served a blank page) On 22 February 2011 04:23, Caldarale, Charles R chuck.caldar...@unisys.comwrote: From: angelicos [mailto:angeli...@gmail.com] Subject: Re: Tomcat won't serve newly created files the reason I know that tomcat is serving the wrong app version is because the login page for the updated app is different to the one tomcat is serving along with several other pages served after logging in, and there are no others apps deployed in the webapp folder. One possibility is that you have a ROOT.xml in conf/Catalina/localhost that defines a different docBase for your webapp. (This was mentioned previously, but you didn't respond to it.) Are you sure you're using the same Tomcat that you place the updated webapp in? (Don't laugh; it happens a lot.) You may also be encountering browser or proxy caching issues. It might be useful to configure a non-proxied Connector, and test with that directly from inside the firewall. The following are the server and context.xml fies: http://fpaste.org/uIsJ/ You actually posted a (possibly partial) web.xml, not a Context element. Where does this web.xml come from? If it's Tomcat's conf/web.xml, be aware that you really shouldn't be putting app-specific security constraints there; they belong in the webapp's WEB-INF/web.xml file. Also, the security settings are incomplete: there's no indication that any form of login is required - but perhaps you're doing that programmatically. If what you posted is the webapp's WEB-INF/web.xml, why did you duplicate so much from the default on in conf/web.xml? In your server.xml, you have both AccessLogValve and FastCommonAccessLogValve enabled; choose one or the other, not both. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- A Hundred Elephants can knock down the walls of a fortress. One diseased rat can kill everyone inside
Re: Tomcat won't serve newly created files
I always do. The problem is, it undeploys the new war file, but it's not using it. It seems to have an old copy of the app stored somewhere else and is using that or context root is being switched to it. Why this is I don't know. But the behaviour is thus; any new files created by the app is created in the nnew undeployed application's directory but attempting to access it means it resolves the file path to the ghost app directory. On 21 February 2011 22:16, Mark Thomas ma...@apache.org wrote: On 21/02/2011 21:52, Lanre Abiwon wrote: I always load with Tomcat stopped. Then you need to delete the expanded ROOT directory as well as replace ROOT.war. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- A Hundred Elephants can knock down the walls of a fortress. One diseased rat can kill everyone inside
Re: Tomcat won't serve newly created files
Apologies. I meant Tomcat Deploys the new warfile but doesn't use the newly deployed app (very tired. Really really long day). Anyway, the reason I know that tomcat is serving the wrong app version is because the login page for the updated app is different to the one tomcat is serving along with several other pages served after logging in, and there are no others apps deployed in the webapp folder. The following are the server and context.xml fies: http://fpaste.org/uIsJ/ On 22 February 2011 03:35, Caldarale, Charles R chuck.caldar...@unisys.comwrote: From: angelicos [mailto:angeli...@gmail.com] Subject: Re: Tomcat won't serve newly created files The problem is, it undeploys the new war file, but it's not using it. What's the it in the above sentence? Why would a new war file be undeployed? It seems to have an old copy of the app stored somewhere else and is using that or context root is being switched to it. You've picked one very unlikely scenario that doesn't really fit any known Tomcat behavior. any new files created by the app is created in the nnew undeployed application's directory What does new undeployed application mean? but attempting to access it means it resolves the file path to the ghost app directory. Any actual evidence of that? Do you see file references to an unexpected location? Still have to think that your redeployment procedure is flawed. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- A Hundred Elephants can knock down the walls of a fortress. One diseased rat can kill everyone inside
Tomcat won't serve newly created files
Hi all I am a bit of a newbie to this so bear with me please. We use Tomcat (Standalone) 5.5.29 on CentOS 5.4 and 5.5 virtual servers. I have a problem in which tomcat won't serve files newly created by the application. The pages return a 404 with the correct file path listed in the message, and I can browse and open the files listed. It will however serve the files already in the folder and I discovered that redeploying the app will work for the newly created files but not for the files created after re-deployment. I'm completely stumped as to why this is happening. The app works fine on the test server which runs on Windows. Thanks for your help
Re: Tomcat won't serve newly created files
No. It's not a 3rd party repackaged tomcat, (downloaded from repos for the Linux machines and from apache on dev server) I've looked through the logs also. Nothing about the 404 error. Regarding where the files are stored, I'm afriad it's in the deployment directory. Not by my design. I just inherited the app. as to what mechanism is being used to serve the files Well https download. On 11/02/2011, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: angelicos [mailto:angeli...@gmail.com] Subject: Tomcat won't serve newly created files We use Tomcat (Standalone) 5.5.29 on CentOS 5.4 and 5.5 virtual servers. Are you using a real Tomcat, or a 3rd-party repackaged one? If the latter, the configuration may enable the security manager, which limits what can be done from a webapp. Make sure you're running with a real Tomcat downloaded from tomcat.apache.org. I have a problem in which tomcat won't serve files newly created by the application. Where are the newly created files being stored? (Inside the webapp's deployment directory would be a very bad answer.) What mechanism is being used to serve the files? Is there anything in the Tomcat logs related to the 404? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- A Hundred Elephants can knock down the walls of a fortress. One diseased rat can kill everyone inside - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat won't serve newly created files
Can you be more specific about their exact location?: They're stored in webapps/ROOT/files. (The actual app folder is renamed to ROOT I was unable to change the app context to the application folder so when the app is deployed the deployed folder is renamed to ROOT. This is something the previous admin guy setup/did so I left it the way it is. Or tried to anyway) Have you verified that the Tomcat userid has read access to those files?: Yes tomcat owns everything in the application folder directory and sub directories thus every file in the webapp directory downwards is listed as being owned by tomcat. Sorry, I should have been more clear. I meant what servlet or JSP is delivering the content? Is it Tomcat's DefaultServlet, or something else?: Upon looking it seems the Default servlet is the one serving the files (I think, but I'm no tomcat guru) What is an example of a failing URL?: https://www.ourcompany.net/files/company/1392534625.jpg You should post the Context element and WEB-INF/web.xml for the webapp; there might be something amiss: http://fpaste.org/wAmw/ as for the context.xml file, everything inside is commented out. On 11/02/2011, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: angelicos [mailto:angeli...@gmail.com] Subject: Re: Tomcat won't serve newly created files I've looked through the logs also. Nothing about the 404 error. Turn on the AccessLogValve in server.xml to get some more information. Regarding where the files are stored, I'm afriad it's in the deployment directory. Can you be more specific about their exact location? Have you verified that the Tomcat userid has read access to those files? as to what mechanism is being used to serve the files Well https download. Sorry, I should have been more clear. I meant what servlet or JSP is delivering the content? Is it Tomcat's DefaultServlet, or something else? What is an example of a failing URL? You should post the Context element and WEB-INF/web.xml for the webapp; there might be something amiss. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- A Hundred Elephants can knock down the walls of a fortress. One diseased rat can kill everyone inside - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
