|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Education won't help those who are proudly and willfully ignorant. They'll literally rather die before changing.
Tim Holloway wrote:Tomcat supports multiple virtual hosts. The concept is not quite identical to how Apache HTTPD does it, but it's similar: you define a Host with a discrete hostname that requests can be sent to.
By default, Tomcat is pre-configured with a single Host, whose name is "localhost". The TOMCAT_HOME/conf/Catalina directory contains 1 subdirectory for each host that that particular Tomcat instance is serving, which is why there's a TOMCAT_HOME/conf/Catalina/localhost directory. It is where the Context definitions are stored for that host when you are deploying with external Context definitions - which is to say that you're neither letting Tomcat synthesize a default definition for a WAR nor using a META-INF/context.xml file within a WAR.
Education won't help those who are proudly and willfully ignorant. They'll literally rather die before changing.
Tim Holloway wrote:Your definition of "clone a server" and mine are not the same. Tomcat allows you to share code with multiple server instances and separate server.xml files (among other resources) by using the CATALINA_HOME and CATALINA_BASE environment variables. In that particular definition of "clone", however, each Tomcat runs as an independent OS process under a separate JVM.
VirtualHosts are defined WITHIN a server. Normally, as I said, there's only "localhost" per server instance, but you can define other virtual hosts as well. Because of the 1-application-per port rule, if you have multiple server instances, each server instance must have at least one Service that defines ports that no other application in the system uses.
The Context is what defines a Tomcat deployed webapp. J2EE actually maintains 2 deployment descriptors: the server-dependent deployment descriptor (Context) and the server-independent deployment description (WEB-INF/server.xml). Together they completely define what a webapp is.
The server-dependent deployment description (Context) is described in the Tomcat system documentation. Basically, this is a small XML file which maps a given URL context (the part of the URL that determines WHICH webapp the URL gets routed to) and the codebase that handles the URL. For simple cases, Tomcat will take a WAR file or exploded WAR directory in the TOMCAT_HOME/webapps directory and build a Context internally whose URL context path is the same name as the WAR and whose codebase is the WAR file or directory.
More complex contexts need explicit definitions. Cases where an explicit Context definition is needed include: webapps which are deployed to some other place than the Host's default WAR directory (TOMCAT_HOME/webapps), webapps that define one or more JDBC connection pools, webapps that employ Tomcat security Realms, and webapps which provide external customization via JNDI parameters.
An explicit context definition can be bundled into the WAR itself in a META-INF/context.xml file or be attached externally as a standalone xxx.xml file in the host's context directory (TOMCAT_HOME/conf/Catalina/localhost, for example). There are precedence rules that determine which context definition is actually used if a context is defined in more than one place.
Education won't help those who are proudly and willfully ignorant. They'll literally rather die before changing.
Tim Holloway wrote:OK, that's an entirely different type of virtual host. Each VM has its own set of TCP/IP ports, so the uniqueness rule doesn't apply. In the simplest configuration, you'd just clone the VM, change its hostname and IP address, and that would essentially be it. No funny messing around with Tomcat's config files.
You'd still need a Context definition if you wanted to use advanced Tomcat configuration options, but that's unrelated to the cloning process. You'd do that even if your had one and only one Tomcat but you needed a Realm or Connection Pool or something like that.
Education won't help those who are proudly and willfully ignorant. They'll literally rather die before changing.
Tim Holloway wrote:I didn't quite understand that, but it sounds like you renamed the host from "localhost" to "servername.domain.org" in the Host element.
Not how the error message reads:
WARNING: Unknown default host [localhost] for connector [Connector[HTTP/1.1-8080]
In other words, don't rename localhost, add a new virtual host and leave localhost alone. It's needed for requests that come into the machine that don't match on the virtual hostname. Even if they are invalid.
However, you don't need a virtual host at all if you are constructing an entire new VM or JVM. In web parlance "virtual host" means "alternative host", and you'd only define them if the machine had more than one hostname with each hostname serving a different set of services.
|
The knights of nee want a shrubbery. And a tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|
