I use Tomcat 8 and have some problem to configure contexts for versioned applications.
I have a set of 4 applications: app1, app2, app3 and app4.
I know how to configure Tomcat to have these 4 applications running directly under webapps: I have folders webapps/app1, webapps/app2,... I define app1.xml, app2.xml,... and I place them in \Tomcat 8.0\conf\Catalina\localhost, and everything works fine.
Now I need to manage different versions of these 4 applications.
To do so:
I have organised my folders like this: webapps/v1/app1, webapps/v1/app2,...,webapps/v2/app1, webapps/v2/app2,..
Based on https://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Defining_a_context: I have defined new context files named v1#app1.xml, v2#app2.xml,..., and I place them in \Tomcat 8.0\conf\Catalina\localhost.
In each of this file, I have set docbase and path, for instance for V1 of app1 I have:
When I restart Tomcat, my applications do not start.
I have propably made one or more mistakes, but English is not my native language and Tomcat doc is not very clear, especially for docbase and path.
So if someone can help me to configure this correctly, thanks in advance.
My recommendation would be that, if you are going to create a non-standard folder structure, to not put the war files under webapps at all. Put them elsewhere, and use the context XML files to map them accordingly.
I don't use war files, each app is made of a set of folders and files, and I copy them under the root folder of the app and restart Tomcat, and it works fine.
If there is a "standard" folder structure for applications with different versions, what is this structure and how to configure it?
Or, if I want to use my structure, how do I name the context files, and what do I put in docbase and path parameters?
Bear Bibeault wrote:
It should be easy to figure out a folder structure that suits your needs and just make sure that the docBase values in the context descriptors match that structure.
If you setup a Context XML file and drop it in conf/Catalina/localhost, the webapp's context path will NOT be the value indicated in the context file. It will be the NAME of the context file
That is, file "foobar.xml" with a Content element of
Will be served at context "/foobar" and not context "/testbed". It's another one of Tomcat's little quirks, like not updating a webapp if you replace a war file but there's already an older exploded WAR of the same name. Fortunately, the docBase attribute is honored and I use that feature extensively. But the path attribute isn't, so beware!
There is no "standard directory structure" in Tomcat. Tomcat webapps are ALWAYS WARs, whether actual WAR files, or their exploded counterparts. You cannot just go dropping files willy-nillly into Tomcat. So the "standard directory" structure is the WAR format as specified in the J2EE spec and Tomcat does not diverge from it.
I am not clear as to whether you truly mean "version" of a webapp or "instance". In Tomcat, there is a many-to-one relationship between contexts and WARs. In other words, I can use /app1, /app2, /app3 and /app4 as contexts (by defining an app1.xml, app2.xml, etc.) and they would all be able to be independent webapp instances based on (and sharing) "mywebapp.war".
Actual webapp versioning is a rather ugly thing that appears to be based on a kludge wherein you tack on a "##"version to the WAR name, then map it to a context or contexts. It strikes me as possibly useful when doing version migrations on a "hot" server, where existing users continue running the older version, but as new users connect, they would be assigned to the newer version until finally the older-version users all signed off and you could safely remove the old WAR. For anything else it seems more trouble than it's worth.
Sources may include data from the Fakebook Research Foundation with support from Gargle University
Tim Holloway wrote:If you setup a Context XML file and drop it in conf/Catalina/localhost, the webapp's context path will NOT be the value indicated in the context file. It will be the NAME of the context file
Yeah, I should have mentioned that -- always name the file the same as the path so that there's no ambiguity.