I've never been able to figure out how to properly use context paths with tomcat. It's really frustrating because reading the docs it seems like it's something that should be very easy, and I know I am not that dumb!!
Now I would like to figure out how to get a similar result using context paths.
I've created appname.xml in $catalina_home/conf/Catalina/localhost/infocenter.xml and tried starting tomcat
<Context path="/blah/infocenter" docBase="/usr/local/tomcat/current/server/webapps/infocenter" debug="0" privileged="false">
I then unjar'ed the war file manually in $catalina_home/server/webapps/infocenter
This seemed to make everything work.
My question is... how can I get tomcat to auto-deploy stuff that lives in $catalina_home/server/webapps/ just like the normal webapps?
I think the big thing I was missing all along is the # based naming of the context.xml files. I had never realized those needed to include # signs for multi level naming conventions. I always thought that's what the context path specified.
Which I guess brings me to my next question... what is the Context path actually doing if it's not telling tomcat what the URI is? It seems like the naming of the xml (blah#infocenter) in this case is what tells tomcat what the URI is going to be.
OK, it's early and my vision is blurry, but I think this may help:
1. Tomcat will automatically scan the TOMCAT_HOME/webapps directory at startup (I use "TOMCAT_HOME" because I can never keep CATALINA_HOME and CATALINA_BASE straight and usually they're the same thing). Any exploded WAR directories are scanned for the presence of a META-INF/context.xml file. If one is found, it will be used to build a Tomcat webapp context - that is, to deploy the exploded WAR. If no such file is found, Tomcat will fake it and assign a context name that's the same as the war directory name.
2. Tomcat will also look for unexploded (a/k/a "real") WARs in the webapps directory. WAR files, in other words. IIF there is no exploded WAR with the same name as the WAR file (minus the ".war extension), then Tomcat will unzip (explode) the WAR file and do the Step 1 process to it. If you update the WAR file, tough. The exploded version takes precedence, even when it's older than the WAR file.
Note that Tomcat doesn't actually HAVE to ever explode WARs. That's just the default behavior.
3. Actually, more like "0". The TOMCAT_HOME/conf/Catalina/localhost directory will be scanned for XML files containing Tomcat Context definitions. These definitions take precedence over webapps in the TOMCAT_HOME/webapps directory. The Context will normally define the URL context name and the docBase for the webapp. The docBase can be either a WAR file or an exploded WAR. I don't actually recommend pointing the docBase to anywhere in Tomcat except for immediately under the TOMCAT_HOME/webapps directory. On a *n*x OS, I used to keep them in "/opt/com/mycompany", although these days, I might use the "/srv" directory as a basis instead.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Mar 26, 2010
Thanks for the responses!
This clarifies things a bit in terms of how the context stuff works. I finally got the context path's working so that's grand.. although the application is misbehaving.. such as life.
Offtopic (sort of) question, but kind of related..
If I compile an apache httpd module on a development server, can I simply move the compiled modules (so files) to my production server, without the need to install any of the supporting libraries etc.. that I needed when I compiled it?
Libraries come in 2 flavors: development libraries and runtime libraries. Well, I could probably come up with more flavors, but for this discussion they'll do. Besides, the paradigm of the Age is black-and-white Absolutes.
The development libraries aren't needed on the production machine. The runtime libraries are. So you'll need compatible versions of those libraries on the production machine and they'll have to be in the httpd server's load library path. At that point, things get a little complicated and very OS-specific, so I'd have to refer you to an OS-specific forum such as the Linux/Unix forum.