This technique was common through Tomcat 4.x, but is deprecated as of Tomcat 5. This technique allows Contexts to be defined in the central server configuration file. A Context element contained within a Host element in the main "conf/server.xml" file This technique can only be used if no context file already exists for the application in hostname directory. Once the "context.xml" file has been renamed and copied to the "" directory, it will not be replaced, even if the WAR is updated with a new "/META-INF/context.xml" file. This "/META-INF/context.xml" file will be automatically copied to "$CATALINA_HOME/conf///", after being renamed to mirror the application's context path. This technique allows context files to be packaged within WARs. An individual file within the application files at /META-INF/context.xml Note that this filename is case-sensitive. You can also use this technique to define the default web application, by creating a file named "ROOT.xml". A file named "test#path.xml" will yield the context path "test/path". The "#" character can be used to define multi-level paths. For example, "test.xml" will yield the context path "/test". The name of each individual XML file will define a new context path. Individual XML files located in $CATALINA_HOME/conf/// CATALINA_HOME/conf///Ĭontexts defined using this technique will have their element information loaded by all web apps contained in the specified host. $CATALINA_HOME/conf/context.xmlĬontexts defined using this technique will have their element information loaded by all webapps. Each of these methods is suited to a specific desired functionality. There are five primary ways in which Contexts can be defined. This Context is required for Tomcat to run properly, because it is considered the "default" web application, responsible for processing requests that do not match any other specific context paths. In the event that the request does not match any specific context paths, Catalina passes the request to a Context whose context path is a zero-length string. In summary, when an HTTP request is made, Catalina receives it, and passes it to the appropriate Context, which in turn passes the request to the appropriate servlet to serve it. Once Catalina has matched a context with a request, the selected Context passes the request to the correct servlet to process the request, based on definitions contained in the web application deployment descriptor file. Tcat lets you save complete server configuration profiles, and apply them to new instances with a single click.
Applications can either be stored in a Web Application Archive (WAR) file, in which case they will be dynamically uncompressed as needed, or as organized unpacked resources in a directory.ĭon't do the same Context configuration work twice. The context path, which is contained within the context, specifies where the application's resources can be located. There is no limit to the number of Contexts that can be defined, as long as each Context is given its own unique context path. Once a Context has been defined, Catalina will attempt to match incoming HTTP requests to its context path. For each explicitly configured web application, there should be one context element either in server.xml or in a separate context XML fragment file. A web site is made up of one or more Contexts. In Tomcat, the Context Container represents a single web application running within a given instance of Tomcat. In this article, we will outline the way that Tomcat uses Contexts to distribute requests to the appropriate servlets, and look at how the methods of defining Contexts vary from one another.