Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml but never updates it?
arjan.tijms schrieb: I always just copy my web application statically to Tomcat's webapps directory ($CATALINA_BASE/webapps) for the production server Insufficient, as Chuck has pointed out: use the manager app. and use MyEclipse for deployment during development. If you use an Eclipse-managed Tomcat, you may then have to right-click on the Server entry in the Servers view and choose Clean. You might want to check what's on the filesystem in the relevant directory before and after cleaning (using something like dir /s /b) so you understand what's going on. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml, but never updates it?
Hi, Michael wrote: I always just copy my web application statically to Tomcat's webapps directory ($CATALINA_BASE/webapps) for the production server Insufficient, as Chuck has pointed out: use the manager app. Does that, basically, mean that the static deployment method is deprecated? If that's true, why doesn't the Tomcat documentation mention this? Currently the documentation says: If you are not interested in using the Tomcat Manager, or TCD, then you'll need to deploy your web applications statically to Tomcat, followed by a Tomcat startup. See: http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html Reading this gives me the impression that I can use it. If I should not use the static deployment mechanism, shouldn't this entry be removed from the documentation? Arjan -- It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml, but never updates it?
M4N - Arjan Tijms schrieb: I always just copy my web application statically to Tomcat's webapps directory ($CATALINA_BASE/webapps) for the production server Insufficient, as Chuck has pointed out: use the manager app. Does that, basically, mean that the static deployment method is deprecated? I'm getting this feeling, too. Static deployment does not seem to handle META-INF/context.xml - and that looks broken. Currently the documentation says: If you are not interested in using the Tomcat Manager, or TCD, then you'll need to deploy your web applications statically to Tomcat, followed by a Tomcat startup. See: http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html Reading this gives me the impression that I can use it. If I should not use the static deployment mechanism, shouldn't this entry be removed from the documentation? It seems misleading indeed. Maybe the description of the deployment sequence should amend this sentence: | 1. Any Context Descriptors will be deployed first. to include a warning like: Achtung! This will only happen if there is no Context Descriptor present at the target location. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml, but never updates it?
Michael Ludwig wrote: M4N - Arjan Tijms schrieb: I always just copy my web application statically to Tomcat's webapps directory ($CATALINA_BASE/webapps) for the production server Insufficient, as Chuck has pointed out: use the manager app. Does that, basically, mean that the static deployment method is deprecated? I'm getting this feeling, too. Static deployment does not seem to handle META-INF/context.xml - and that looks broken. No, static deployment is not deprecated. Static deployment *does* handle context.xml. It is working as designed. If you delete the WAR/DIR *and wait for Tomcat to spot this* then any CATALINA_BASE/engine/host/context.xml will be deleted. If you overwrite the WAR/DIR then the CATALINA_BASE/engine/host/context.xml will be left alone. Currently the documentation says: If you are not interested in using the Tomcat Manager, or TCD, then you'll need to deploy your web applications statically to Tomcat, followed by a Tomcat startup. See: http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html Reading this gives me the impression that I can use it. If I should not use the static deployment mechanism, shouldn't this entry be removed from the documentation? It seems misleading indeed. Maybe the description of the deployment sequence should amend this sentence: | 1. Any Context Descriptors will be deployed first. This means any files found in CATALINA_BASE/engine/host/context.xml Any suggestions to clarify the docs are welcome. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml, but never updates it?
Mark Thomas schrieb: Michael Ludwig wrote: Static deployment does not seem to handle META-INF/context.xml - and that looks broken. No, static deployment is not deprecated. Static deployment *does* handle context.xml. It is working as designed. If you delete the WAR/DIR *and wait for Tomcat to spot this* then any CATALINA_BASE/engine/host/context.xml will be deleted. Not rather $CATALINA_BASE/conf/[engine]/[host]/[appname].xml ? And does it also apply when the [appname].xml wasn't copied there by Tomcat but placed there by the admin? I suspected that Tomcat doesn't distinguish between the two cases. If you overwrite the WAR/DIR then the CATALINA_BASE/engine/host/context.xml will be left alone. This should go into the doc (possibly in corrected form), unless it is there in some form and we haven't seen it. Currently the documentation says: If you are not interested in using the Tomcat Manager, or TCD, then you'll need to deploy your web applications statically to Tomcat, followed by a Tomcat startup. See: http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html This seems to imply that you have to shut down Tomcat before static deployment. It seems misleading indeed. Maybe the description of the deployment sequence should amend this sentence: | 1. Any Context Descriptors will be deployed first. This means any files found in CATALINA_BASE/engine/host/context.xml Just to be 100% sure, does that mean: Any WARs or web application directories referenced from Context Descriptors found in $CATALINA_BASE/conf/[engine]/[host]/ ? Like: C:\MILU\Server\Tomcat60\conf\Catalina\localhost\import.xml C:\MILU\Server\Tomcat60\conf\Catalina\localhost\xpgj.xml -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml, but never updates it?
Michael Ludwig wrote: Mark Thomas schrieb: Michael Ludwig wrote: Static deployment does not seem to handle META-INF/context.xml - and that looks broken. No, static deployment is not deprecated. Static deployment *does* handle context.xml. It is working as designed. If you delete the WAR/DIR *and wait for Tomcat to spot this* then any CATALINA_BASE/engine/host/context.xml will be deleted. Not rather $CATALINA_BASE/conf/[engine]/[host]/[appname].xml ? Correct. I was being lazy. And does it also apply when the [appname].xml wasn't copied there by Tomcat but placed there by the admin? I suspected that Tomcat doesn't distinguish between the two cases. Also correct. If you overwrite the WAR/DIR then the CATALINA_BASE/engine/host/context.xml will be left alone. This should go into the doc (possibly in corrected form), unless it is there in some form and we haven't seen it. Fourth bullet of this page: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html Currently the documentation says: If you are not interested in using the Tomcat Manager, or TCD, then you'll need to deploy your web applications statically to Tomcat, followed by a Tomcat startup. See: http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html This seems to imply that you have to shut down Tomcat before static deployment. That all depends what risks you are prepared to take. There is a chance that Tomcat will spot the updated WAR and start to deploy it before the copy has finished. If this happens then the deployment will be corrupted. Larger WARs and copying over a slow network connection make this more likely. A local move is far less likely to have an issue but there is always a chance. It seems misleading indeed. Maybe the description of the deployment sequence should amend this sentence: | 1. Any Context Descriptors will be deployed first. This means any files found in CATALINA_BASE/engine/host/context.xml Just to be 100% sure, does that mean: Any WARs or web application directories referenced from Context Descriptors found in $CATALINA_BASE/conf/[engine]/[host]/ ? Correct. The deployer how-to probably needs: a) some tweaks b) a reference to the context config page Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml but never updates it?
p.s. M4N - Arjan Tijms wrote: I'm running Tomcat 6.0.20 using JDK 6 update 14 on a 64 bits Debian Lenny. I've unpacked a stock Tomcat 6.0.20 and deployed a web module to the webapps directory. After I started and stopped the web module, I noticed that the META-INF/context.xml had been copied to conf/Catalina/localhost/[name of web module].xml. When I try to make the [tomcat install dir]/conf read only, I get the following exception when starting up: INFO: Starting Coyote HTTP/1.1 on http-8080 Aug 6, 2009 6:52:07 PM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 Aug 6, 2009 6:52:07 PM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/19 config=null Aug 6, 2009 6:52:07 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 137 ms Aug 6, 2009 6:53:17 PM org.apache.catalina.startup.HostConfig deployDirectory SEVERE: Error deploying web application directory my_test java.io.FileNotFoundException: /opt/apache-tomcat-6.0.20/conf/Catalina/localhost/my_test.xml (No such file or directory) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:957) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:909) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:495) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1274) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:296) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590) at java.lang.Thread.run(Thread.java:619) It thus appears that Tomcat really wants to make this copy first and then process only this copy. I however very much want this not to happen. Is there any option that allows me to change this? What I need is the Tomcat 6.0.18 and earlier behavior where META-INF/context.xml is used from the webapps/someapp directory as-is, without any copying of any kind. Thanks in advance for all help -- It's a cult. If you've coded for any length of time, you've run across someone from this warped brotherhood. Their creed: if you can write complicated code, you must be good. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml but never updates it?
M4N - Arjan Tijms wrote: Hi, I'm running Tomcat 6.0.20 using JDK 6 update 14 on a 64 bits Debian Lenny. I've unpacked a stock Tomcat 6.0.20 and deployed a web module to the webapps directory. After I started and stopped the web module, I noticed that the META-INF/context.xml had been copied to conf/Catalina/localhost/[name of web module].xml. I made a change to META-INF/context.xml and started Tomcat again, but the copy in conf/Catalina/localhost/ appeared to be not updated. I stopped Tomcat, removed the web module from webapps and started Tomcat again. The copy in conf/Catalina/localhost still wasn't updated/deleted and now Tomcat started complaining it couldn't find my webapp anymore. I've been a long time Tomcat user and this has never ever been a problem for me. I never noticed conf/Catalina/localhost contained a copy of my context.xml files, but I could always modify context.xml and never needed to explicitly delete the contents of conf/Catalina/localhost. This is a rather scary situation. I'm not 100% sure why Tomcat does this copying in the first place and I'm not at all sure what's going on with the stale copies. Anyone has any idea? Search the archives. This been covered repeatedly. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml but never updates it?
Mark Thomas schrieb: M4N - Arjan Tijms wrote: Anyone has any idea? Search the archives. This been covered repeatedly. Hint: Tomcat has a manager app. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml but never updates it?
Search the archives. This been covered repeatedly. Mark Mark, I did try to search extensively, even after posting. A while after my post I continued searching but the only post that appeared at the top of the search results happened to be my very own post. I searched using keyword conf/Catalina, tomcat 6.0.20 conf/Catalina, context.xml copied context.xml not changed tomcat doesn't pick up changes context.xml changed context.xml ignored, etc. As I mentioned, I'm a long time Tomcat user. I always just copy my web application statically to Tomcat's webapps directory ($CATALINA_BASE/webapps) for the production server and use MyEclipse for deployment during development. The Tomcat deployment documentation doesn't mention this copying and not updating of context.xml at all: http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html It says this: The locations for Context Descriptors are; $CATALINA_BASE/conf/[enginename]/[hostname]/context.xml $CATALINA_BASE/webapps/[webappname]/META-INF/context.xml Files in (1) are named [webappname].xml but files in (2) are named context.xml. If a Context Descriptor is not provided for a Context, Tomcat configures the Context using default values. And this: If you are not interested in using the Tomcat Manager, or TCD, then you'll need to deploy your web applications statically to Tomcat, followed by a Tomcat startup. The location you deploy web applications to for this type of deployment is called the appBase which is specified per Host. You either copy a so-called exploded web application, i.e non-compressed, to this location, or a compressed web application resource .WAR file. The web applications present in the location specified by the Host's (default Host is localhost) appBase attribute (default appBase is $CATALINA_BASE/webapps) will be deployed on Tomcat startup only if the Host's deployOnStartup attribute is true. The following deployment sequence will occur on Tomcat startup in that case: Any Context Descriptors will be deployed first. Exploded web applications not referenced by any Context Descriptor will then be deployed. If they have an associated .WAR file in the appBase and it is newer than the exploded web application, the exploded directory will be removed and the webapp will be redeployed from the .WAR .WAR files will be deployed Note again that for each deployed web application, a Context Descriptor will be created unless one exists already. The first line of the second quote then you'll need to deploy your web applications statically to Tomcat is my use case. I'm interested in doing the static deploy. The last line says that a Context Descriptor will be created, *unless* one exists already. The first quote makes it clear that $CATALINA_BASE/webapps/[webappname]/META-INF/context.xml qualifies as a Context Descriptor. My web module/application contains a context.xml, yet Tomcat creates one in conf/Catalina by copying the one from my (exploded) static deployment. I'm frantically reading through every piece of Tomcat documentation that I can get my hands on, but I just can't find a reference to this copying. Meanwhile I'll try scanning every post in the Tomcat mailing list archive manually, as my keyword searches seem to bring me nothing. It would be very much appreciated if you could give me some keywords to search on. An actual link would be even better of course, but I'm absolutely willing to do the searching myself. To be sure, I want to make it clear that I've been able to deploy statically to almost each and every version of Tomcat since the late 4.x revisions. A version as recent as Tomcat 6.0.18 didn't seem to have this problem. Thanks in advance for all help. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml but never updates it?
arjan.tijms wrote: Search the archives. This been covered repeatedly. Mark Mark, I did try to search extensively, even after posting. A while after my post I continued searching but the only post that appeared at the top of the search results happened to be my very own post. I searched using keyword conf/Catalina, tomcat 6.0.20 conf/Catalina, context.xml copied Then I think you need to use a better search engine. I'd recommend MarkMail. Trying your third search above gives this: http://tomcat.markmail.org/search/context%2Exml+copied+list:org%2Eapache%2Etomcat%2Eusers+order:relevance The Tomcat deployment documentation doesn't mention this copying and not updating of context.xml at all: Try looking at the doc for Context elements. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml but never updates it?
On Thu, 06 Aug 2009 23:52:24 +0200, arjan.tijms arjan.ti...@m4n.nl wrote: Search the archives. This been covered repeatedly. Mark I did found this posting: http://mail-archives.apache.org/mod_mbox/tomcat-users/200906.mbox/%3c4a3f56c9.8050...@apache.org%3e You explain here the copying of the context.xml that's within a .war archive and a few posts later the reasons for doing so. Although maybe not explicitly documented, it seems Tomcat has been doing this at least for a while for .war archives. However, in my case I'm statically deploying an *exploded* web application. I just tested whether earlier Tomcat versions copied context.xml (I used Tomcat 6.0.14, 6.0.16 and 6.0.18) and none of these did the copying for static exploded deployments. Can you confirm that copying for exploded deployments is a new and intended behavior for Tomcat 6.0.20? If this is indeed intended behavior, then what is the rationale for it? Unlike for .war deployments, I can just edit the embedded context.xml in an exploded deployment directly so the unpack, edit, pack problems aren't an issue here. Also, for development I'm running into issues too with the new behavior. If I edit the context.xml file in Eclipse and save it, then Tomcat 6.0.18 would pick up the changes. Since my IDE has no knowledge about the file in conf/Catalina the result is that changes don't seem to be picked up. Manually deleting the file in conf/Catalina on the command line outside my IDE is of course not difficult but tedious nevertheless. Also, in this post http://mail-archives.apache.org/mod_mbox/tomcat-users/200906.mbox/%3c4a3f70cb.8050...@apache.org%3e you say: If you want to remove the old configuration, undeploy the app first which will remove the old configuration file. But what counts as an undeploy for a static deployment? If I just delete my statically deployed application from the webapps directory and restart Tomcat, then the files in conf/Catalina are still there. Instead of removing the configuration files, Tomcat gives the error that it can't find the matching webapp anymore. Does this undeploy that should remove the configuration file only works when undeploying via the manager app? Arjan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat copies context.xml to conf/Catalina/localhost/app.xml but never updates it?
arjan.tijms wrote: On Thu, 06 Aug 2009 23:52:24 +0200, arjan.tijms arjan.ti...@m4n.nl wrote: Search the archives. This been covered repeatedly. Mark I did found this posting: http://mail-archives.apache.org/mod_mbox/tomcat-users/200906.mbox/%3c4a3f56c9.8050...@apache.org%3e You explain here the copying of the context.xml that's within a .war archive and a few posts later the reasons for doing so. Although maybe not explicitly documented, it seems Tomcat has been doing this at least for a while for .war archives. However, in my case I'm statically deploying an *exploded* web application. I just tested whether earlier Tomcat versions copied context.xml (I used Tomcat 6.0.14, 6.0.16 and 6.0.18) and none of these did the copying for static exploded deployments. Can you confirm that copying for exploded deployments is a new and intended behavior for Tomcat 6.0.20? Did you look at the changelog? But what counts as an undeploy for a static deployment? If I just delete my statically deployed application from the webapps directory and restart Tomcat, then the files in conf/Catalina are still there. Using the manager app will guarantee a proper undeployment. Just deleting the directory whilst Tomcat is running should be sufficient providing you have autoDeploy enabled and Tomcat has a chance to spot the directory has been deleted before you copy the new version across. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
