Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you an example analysis of Tomcat directory deployment and Context description file context.xml. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

After the development of Web applications, some projects sometimes take the form of directory deployment and add Context configuration to server.xml, such as the following:

However, this configuration is not officially encouraged, and the same effect can be achieved through two forms of configuration in external files without affecting the Tomcat master configuration.

$CATALINA_BASE/conf/ [enginename] / [hostname] / [webappname] .xml

$CATALINA_BASE/webapps/ [webappname] / META-INF/context.xml

Earlier, I wrote about the application deployment of Tomcat (how is the WEB application deployed? how to deploy multiple versions of the application in Tomcat), but context.xml was not introduced in detail at that time.

With regard to the two forms mentioned above, the content is the same, but it is configured in different locations. For example, for the content configured in server.xml above, you can create a file named test.xml and store it in the conf/localhost/test.xml of Tomcat, that is, in the first case of the above two items. Note here that the name of the application will directly use the file name, and the configuration of path will be ignored.

Strictly speaking, the second method does not directly replace the situation in the previous server.xml, what it can solve is the additional configuration for deploying applications in the webapps directory, such as manager, to increase remote access restrictions (why your Manager login is not successful?) is achieved by adding context.xml in the META-INF directory.

In essence, these two kinds of description files (Context Descriptor) are called Context. These description files contain some application-specific configurations for Context, such as configuring Session Manager, specifying naming Resrouce, defining SessionCookie names, and so on. Using the description file is equivalent to customizing the Context. If the application of the description file is not provided, Tomcat will directly initialize the application with the default value.

What's more, applications defined using description files will be deployed first.

Let's take a look at the source code.

Source code

In HostConfig, all deployments start here.

Protected void deployApps () {

File appBase = host.getAppBaseFile ()

File configBase = host.getConfigBaseFile ()

String [] filteredAppPaths = filterAppPaths (appBase.list ())

/ / Deploy XML descriptors from configBase

DeployDescriptors (configBase, configBase.list ())

/ / Deploy WARs

DeployWARs (appBase, filteredAppPaths)

/ / Deploy expanded folders

DeployDirectories (appBase, filteredAppPaths)

}

We see the deployment order:

Deployment XML description file

Deploy WAR applications

Deploy decompressed Web applications

The directory to read the application is the configuration corresponding to the appBase corresponding to each Host, and our commonly used webapps directory is the default location of the virtual host localhost.

The deployment descriptor, the first type of webappname.xml, traverses all the xml description files from the configBase and then deploys them.

For (int I = 0; I < files.length; iTunes +) {

File contextXml = new File (configBase, files [I])

If (Files [I] .toLowerCase (Locale.ENGLISH) .endsWith (".xml")) {

ContextName cn = new ContextName (files [I], true); / / look here

If (isServiced (cn.getName ()) | | deploymentExists (cn.getName ()

Continue

Results.add (

Es.submit (new DeployDescriptor (this, cn, contextXml))

}

}

For (Future result: results) {

Try {

Result.get ()

} catch (Exception e) {

Log.error (sm.getString (

"hostConfig.deployDescriptor.threaded.error"), e)

}

}

Note that the line of code generated by ContextName directly uses the file name to set up Context. ContextName we have seen the source code in the previous article, and what is configured here is path, that is, the name of the actual requested application.

Then in the actual deployment, first obtain the Context object through the Digester parsing file, and then configure the properties, and then the deployment process is the same as the others.

In the initialization process of StandardContext, it is determined to get the previously set configFile object, and if it is not empty, the contents of the file will be parsed.

Our second approach above is to provide context.xml for the application, which is called ApplicationContextXml in the Tomcat code.

This file parses whether context.xml is included in the META-INF directory during the second and third deployments, and then sets the configFile property of Context. When initializing Context, you will have the following logic

If (context.getConfigFile ()! = null) {

ProcessContextConfig (digester, context.getConfigFile ())

}

This is the process you took after setting up configFile in webappname.xml parsing, in ContextConfig.

In this way, our custom configuration file takes effect in Tomcat.

The above is the example of Tomcat directory deployment and Context description file context.xml shared by Xiaobian. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.