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

For Tomcat servers, you can place multiple websites (multiple web applications), that is, configure multiple virtual hosts, as if there are multiple hosts, and each host has a web application. As mentioned in the previous article, for the Tomcat server, a tag represents a virtual host in the server.xml file, and the default virtual host was used in the previous article, which is defined in the server.xml file:

...

You can see that the name of the existing virtual host ("localhost") happens to be the name of the host where the browser accesses the loopback address of the machine. The appBase attribute is the directory where the web application is stored, autoDeploy refers to whether it is automatically deployed, and unpackWARs refers to whether to decompress the war package automatically. If it is false, run the application directly from the war package without decompression.

We want to configure multiple virtual hosts in the same way, add tags in the server.xml file, specify the name attribute and appBase attribute, and then add the web application.

Usually, the way of configuring virtual hosts is related to the domain name of the website, but I do not have the URL of the domain name, so I directly modify the hosts file to redirect the domain name as learning to add and configure the virtual host in the server.

Modify the server.xml file in the Tomcat server, add a tag, use the "domain name" method for the name attribute, and place the directory [fjdingsd] where the virtual host stores the web application under the [D] disk where the Tomcat is not located:

In the [news] directory:

After adding the virtual host to the server.xml, directly place the web application in the corresponding virtual host to store the web application directory. Note that here is the [fjdingsd] directory under disk D defined by appBase in the label, and my web application [news] should be put in it. There is a custom home.html file in the directory where my web application is located.

Now I need to bind the defined virtual hostname to ip, because I am not registered with the DNS server, so I use the hosts file to bind my virtual hostname to the native ip address:

Start the Tomcat server like this, type in the browser, and you can see:

In this way, a virtual host is configured, and there are web applications in the virtual host.

Here is just a small try on the virtual host configuration of the Tomcat server, and if you really want the outside world to access our configured virtual host (website), you should register the domain name with the DNS server.

No matter how many virtual hosts are added to the Tomcat server, they are eventually converted to ip addresses to access the server. There is a problem here: if every web application sets up the home page and does not enter the domain name in the browser, but opens it directly through the ip address, how does the server know which virtual host to go to for resources?

The answer lies in the engine of the Tomcat server, where the default virtual host of the Tomcat server is defined by the tag in the server.xml file:

......

So if I want to change the default virtual host for the Tomcat server, I change the "defaultHost" attribute in the tag.

=

If you want to deploy the developed web application to a remote server, you can compress the web application into war format, and then transfer it. During the operation of the Tomcat server, if a new war package is detected in the directory where the web application is stored, it will be automatically decompressed and deployed (unpackWARs attribute and autoDeploy attribute in). This approach is best suited for delivering and managing new web applications to remote servers.

So how to package the developed web application with war:

Type "jar-cvf application name. war application name" in cmd.

If my web application is the [news] directory in the [fjdingsd] directory under disk D, then I should type this in cmd: jar-cvf news.war news

And get the war file:

Then put the news.war into the [webapps] directory of Tomcat, and Tomcat will decompress it automatically in a few seconds. The Tomcat server must be opened before you can see the process of automatic decompression.

After 3 or 4 seconds:

If you delete the war package that has been automatically extracted while Tomcat is running, Tomcat will automatically delete the unzipped web application in a few seconds.

If the war package is placed in the [webapps] directory before the Tomcat server is started, then Tomcat will be automatically unzipped and deployed after startup.

If the war package is unzipped by Tomcat and the war package is deleted after Tomcat is closed, then the web applications extracted by the war package before starting Tomcat will not be deleted.

The architecture of Tomcat

The architecture of Tomcat can be analyzed from its most important server.xml file, and the following is an architecture diagram of Tomcat:

Combined with the server.xml file, you can see:

After the Tomcat starts, that is, the server (tag), some listeners () and some globally named resources () are also started.

In addition to the server (tag) being started, the "service" () is also started, just like the "services.msc" typed in cmd.

There will be various connectors () under the service (), as shown in the architecture diagram above, where the connector () that deals with the browser defines properties such as connection protocol (protocol), connection port (port), connection timeout (connectionTimeout), and so on, as well as connectors for other purposes.

Under the service (), in addition to various connectors (), there is an engine (). When the browser sends some requests, it gives it to the engine () through the connector (). The engine () can contain one or more virtual hosts (). The engine also specifies which virtual host is accessed by default.

The engine () sends the request to it by looking for the specified virtual host (), and then the virtual host () finds which web application it is. The virtual host () defines the host name that the browser needs to enter, the location where the web application is stored, and some other properties, and so on.

As for what kind of web application depends on which kind of virtual directory mapping is used, if it is added, then a tag represents a web application.

Or directly place the directory where the web application is located in the path specified by the label, then there is no label to represent the web application.

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.