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

This article will explain in detail about the configuration and principle of Tomcat multi-virtual host, the content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

For most of our Tomcat users, the basic use of Tomcat is to deploy applications and make application requests in browsers. And the format of this application request looks like this:

Http://localhost:8080/Web

Where 8080 is the listening port corresponding to Connector, Web is the application corresponding to the request, and localhost is the protagonist of this time, corresponding to a virtual host contained by default in Tomcat, and corresponding to the Host container in Tomcat.

This configuration is included by default in the configuration file server.xml of Tomcat.

By default, all our applications are deployed to this virtual host, so the previous requests for applications are transferred to the localhost Host by Connector.

Let's take a look at the concept of virtual hosting. Compared with the physical host, it virtualizes multiple mechanisms that can be run by different sites on one machine.

In Tomcat, if you want to support multiple virtual hosts, it is relatively easy to configure.

Within the components of Engine, just add configuration information about Host. For the corresponding attributes, you can refer to the default localhost host.

In the hosts file of the operating system, add the mapping of your newly created virtual host name to IP.

You can choose to add components such as AccessLog to the current host.

Restart Tomcat for the changes to take effect.

Suppose our new virtual hostname is remoteHost, and in the browser, we can use the

Http://remoteHost:port/Webapp

This is the way to access the application.

The application deployment of a new virtual host can be specified by configuring the appBase attribute of the host.

Of course, in addition to the above configuration, a defaultHost can be configured on the Engine container, that is, after the Connector hands over the request to Engine, if the corresponding Host cannot respond to the request, it will be transferred to defaultHost for processing.

At this point, you may find that the applications between multiple virtual hosts are isolated, just as we want to build a website to buy space, we can only access the resources and content corresponding to our own host. How is this isolation of applications between hosts realized in Tomcat?

We know that in Tomcat, the whole service is provided externally, which is abstracted as Service. In server.xml, it corresponds to the configuration of Service. The default implementation of service is StandardService. In the implementation, a declaration of such a Field is included:

Protected final MapperListener mapperListener =

New MapperListener (mapper, this)

It is also essentially a component that starts, stops, and so on according to the life cycle of the LifeCycle. The following is its corresponding class declaration:

Public class MapperListener extends LifecycleMBeanBase

Implements ContainerListener, LifecycleListener

In the start method of Service, the start of MapperListener is also called. During the startup process of mapperListener, you will register yourself in the listener of Engine, and all subsequent container lifecycles will be notified. This is the use of the observer mode. (see here: learn the design pattern from Tomcat | publish-subscribe mode)

Engine engine = (Engine) service.getContainer ()

AddListeners (engine); / / here is the registration

Container [] conHosts = engine.findChildren ()

For (Container conHost: conHosts) {

Host host = (Host) conHost

If (! LifecycleState.NEW.equals (host.getState () {

/ / Registering the host will register the context and wrappers

RegisterHost (host)

}

}

We see that at startup, all the Host under Engine will be registered. Let's see what the registration here is doing.

Private void registerHost (Host host) {

String [] aliases = host.findAliases ()

Mapper.addHost (host.getName (), aliases, host)

For (Container container: host.findChildren ()) {

If (container.getState () .isAvailable ()) {

RegisterContext ((Context) container)

}

}

}

The mapper here is another field created in StandardService. The Host registered here, as well as the corresponding registerContext in the above method, are added to the mapper for parsing when later requests are processed.

The most important thing for the addHost here is to do such an operation.

MappedHost [] newHosts = new MappedHost [hosts.length + 1]

MappedHost newHost = new MappedHost (name, host)

If (insertMap (hosts, newHosts, newHost)) {

Hosts = newHosts

}

When registering Context later, the method is basically the same. When it comes to application request parsing, the process is similar to the following: (request processing can be referred to: and Tomcat learn design pattern | Facade mode and request processing, how does Tomcat handle request parameters? )

When Connector passes the request to CoyoteAdaptor, after the request header processing, some post-processing is done on the request and response objects, which is passed to peipeline for the request.

In this process, the following processing will take place:

Connector.getService (). GetMapper (). Map (serverName, decodedURI)

Version, request.getMappingData ()

The Mapper associated with the service is used to determine based on the mappingData of the request, and the request URI and context are mapped. At this time, the registration mentioned above will be used.

/ / Virtual host mapping

MappedHost [] hosts = this.hosts

MappedHost mappedHost = exactFindIgnoreCase (hosts, host)

If (mappedHost = = null) {

If (defaultHostName = = null) {

Return

}

MappedHost = exactFind (hosts, defaultHostName)

If (mappedHost = = null) {

Return

}

}

MappingData.host = mappedHost.object

/ / Context mapping

ContextList contextList = mappedHost.contextList

MappedContext [] contexts = contextList.contexts

Int pos = find (contexts, uri)

If (pos =-1) {

Return

}

In the red marks above, hosts is the object that was changed when registering Host. DefaultHostName is the default host configured for Engine, which is mentioned at the beginning. If other hosts cannot find resources, use it to respond. We can see that the mapping of the application is based on Host, and then look for its corresponding ContextList from here. So the applications of different hosts are isolated.

The above is the principle of multi-virtual host configuration in Tomcat and its internal application isolation and registration.

In the application deployment phase, the register will be conducted separately according to the host and the applications deployed on it.

When applying the request, look for the mapping on the corresponding host according to the Context relationship established during deployment

DefaultHost can be configured for Engine to respond when resources are not found on a specific host

About Tomcat multi-virtual host configuration and principle of what to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.