Tomcat Web Hosting Blog - Java, JSP, EJB, Hibernate

Chapter 15: Shared Tomcat Hosting must be determined is whether Tomcat could handle the servlets and JSPs while distinguishing the various hosts involved. Of course, the Apache Web server can be used to perform additional tasks such as load balancing and clustering. These configuration options are not generally considered for virtual hosting, and are discussed separately in Chapters 11 and 17 . The task of configuring virtual host support in Tomcat consists of two steps adding a virtual host supporting Web application definition, which is sufficient if Tomcat is being run as a standalone server, and adding suitable directives in the Apache configuration file ( $APACHE_HOME/conf/httpd.conf ), if Tomcat is being run as an external Servlet engine. Let s look first at the scenario in which Tomcat is used as a standalone server, serving static pages as well as JSPs and servlets. Example Deployment Scenario Before you continue configuring Tomcat for virtual hosting, take a look at the example deployment scenario that will be used in the rest of the chapter. This section covers configuring Tomcat to serve two fictitious virtual hosts: europa.domand callisto .dom on the same Tomcat instance. To ensure that these domains are really fictitious, we have even chosen the fictitious TLD (top level domain) name dom. In this example, we add our own DNS entries for the virtual hosts, so using a fictitious TLD is not a problem. Naturally, these virtual hosts will be running on the same IP address for name-based virtual hosting, and on different IP addresses for IP-based virtual hosting. It is likely that in a production scenario, both these domains would be hosted on a directory outside the Tomcat base directory. The hosting scheme that is to be used is as follows. Each of the domains would have its own document area in / home/websites/ . Web applications or WAR files would be deployed in a subdirectory named webapps. Static HTML pages and scripts, if required, can be kept separate from the Web applications, and would be deployed in a subdirectory named web. As an example for the domain europa.dom, a Web application called shopwould be deployed under /home/websites/europa.dom/webapps/shop. Alternatively, the shop.war Web application archive could be deployed under /home/websites/europa.dom/webapps/. If the Web application needs to be available as the default context (i.e., http://europa.com/and not http://europa.com/shop/ ), then it needs to be deployed as /home/websites/europa.dom/webapps/ROOT/. If Apache is required to serve static pages and scripts, they would be deployed to a separate location, which is used as the document root, such as /home/websites/europa.dom/web/. The static Web pages need not be served by Apache; they can very well be served by Tomcat itself. In that case, these are placed under /home/websites/europa.dom/webapps/ROOT(for the default context) or under /home/ websites/europa.dom/webapps/ (all other contexts) . However, in many shared hosting environments it makes sense to keep the Web applications separate from the static pages. This is because in a lot of shared hosting plans, Tomcat support is often an additional feature. For most of the clients static site content, the separate Web directory would suffice, and Apache would handle them without any problems. For clients who want to add Java Web applications to their plan, it is a simple matter to deploy their WAR files in the webapps/ directory without mixing them up with the static content.

If you looking for unlimited one inclusive web hosting plan please check unlimited web hosting website.

Chapter 15: Shared Tomcat Hosting address ( http://192.168.1.2), Apache is not able to resolve which Web site to serve and will serve you content from the default virtual host, which is the first one listed in the httpd.conffile in this case, europa.dom. Avoiding Common Issues Some common issues to avoid in name-based virtual hosting include the following: . If a Web request has been made to an IP address listed in the NameVirtualHostand the applicable virtual host could not be determined, Apache sends the request to the first virtual host block in the Apache configuration for that IP address. The request is not sent to the default document root of the whole server. Therefore, the first section for every NameVirtualHost IP address should be a domain where unresolved Web requests could also be handled. . It is not possible to have SSL/HTTPS support using name-based virtual hosts because of the nature of the SSL protocol itself. For establishing the connection between the client and server, the SSL protocol parameters first need to be negotiated. For this to happen, the client has to know which server to connect to, which can t happen as the Host:header hasn t yet been exchanged to determine which virtual host to send the request to. This chicken-and-egg issue is the reason why each SSL-enabled Web site must be configured on a unique IP address. The only option here is to use IP-based virtual hosting. . Older Web clients and many Web access software libraries still use the old HTTP 1.0 protocol. Because they don t send the Host: header to the Web server, name-based virtual hosting would not work properly with them. However, these incompatible clients are incredibly rare. It is unlikely that excluding them from a list of supported clients would cause a significant problem. All major browsers, such as Firefox, Netscape (version 2.0+), Internet Explorer (version 3.0+), and Lynx (1995+), support the Host:header. Virtual Hosting in Tomcat The preceding section explained how to configure Apache to support virtual hosts. This section contains the main focus of this chapter: virtual host support in Tomcat. Before reading further, it is important to consider what would be expected from Tomcat in a shared hosting environment. Tomcat could work either in a standalone mode (in which it includes support for both an HTTP server and the JSP/Servlet container) or in a cooperative manner (with a Web server such as Apache). Chapter 11 provides details on various ways to set up Tomcat with the Apache Web server. Expecting Tomcat to provide virtual hosting support would mean the following: Given that two or more Web hosts are served from the same machine, when a request comes for a particular resource on one of these hosts, Tomcat should be able to successfully identify the host for which the request had been received, and fetch the required resource from the host document base. For Tomcat working in a standalone mode, the request in question can target static pages, as well as JSP and servlets. When working along with another Web server such as Apache, the Web server itself handles the virtual hosts and the processing of subsequent static pages. Therefore, the only thing that

For high quality java hosting services please check tomcat web hosting website.

Chapter 15: Shared Tomcat Hosting ServerName callisto.dom DocumentRoot /home/websites/callisto.dom/web ServerAdmin support@callisto.dom ErrorLog /home/websites/callisto.dom/log/error TransferLog /home/websites/callisto.dom/log/access As mentioned earlier in the chapter, some old browsers do not send the Host: header required for name-based virtual hosting to work. There is a workaround in Apache for these browsers using the Apache ServerPath directive. To use this directive, add the following to the virtual host settings: NameVirtualHost 192.168.1.2 ServerName europa.dom ServerPath /europa DocumentRoot /home/websites/europa.dom/web ServerAdmin support@europa.dom ErrorLog /home/websites/europa.dom/log/error TransferLog /home/websites/europa.dom/log/access … Once this is done, all requests for a Web page containing /europa can be accessed by older browsers (the ones that don t send the Host:parameter) at http://europa.dom/europa, and by the modern browsers at http://europa.dom. The Web developer would need to make sure that both locations work, for example by putting links between the two locations. This is not a clean workaround; if an older browser doesn t send a Host: parameter and requests http://callisto.dom/europa for instance, Apache serves up content for the europa.dom Web site and not callisto.dom! Testing Your Configuration Finally, the following summarizes the steps you need to take to configure name-based virtual hosting on Apache: 1. Make DNS changes, or edit hosts file for the hosts that you wish to run Apache on. In name- based virtual hosting, different host names can share the same IP address. 2. Edit Apache s httpd.confconfiguration file and add NameVirtualHost directives for each of the virtual hosts as shown in the previous section. 3. Edit the httpd.confconfiguration file and add VirtualHostsections for each of the virtual hosts, as shown in the previous section. 4. Make sure that the DocumentRootin each VirtualHostsection points to the location of the Web site content for the virtual host. 5. Restart Apache using the apachectlcommand. You should now be able to start your browser and view the respective Web sites. You can do this using only the host names of the Web sites ( http://callisto.dom, http://europa.dom). If you use the IP

For high quality java hosting services please check tomcat web hosting website.

Chapter 15: Shared Tomcat Hosting The additional Host: header in the client request helps the Web server distinguish between all the domains that share the same IP address. Configuring Name-Based Virtual Hosting in Apache Implementing name-based virtual hosting in Apache is not very different from implementing IP-based virtual hosting. It requires only the addition of the NameVirtualHost directive. This directive configures the IP address on which the Apache server will receive HTTP requests for the name-based virtual hosts. Documents should be subsequently fetched depending on the value of this parameter and the related virtual host definition specified later in the configuration. A sample Apache name-based configuration for a Linux/Unix system would look like the following: Listen 80 … NameVirtualHost 192.168.1.2 ServerName europa.dom DocumentRoot /home/websites/europa.dom/web ServerAdmin support@europa.dom ErrorLog /home/websites/europa.dom/log/error TransferLog /home/websites/europa.dom/log/access ServerName callisto.dom DocumentRoot /home/websites/callisto.dom/web ServerAdmin support@callisto.dom ErrorLog /home/websites/callisto.dom/log/error TransferLog /home/websites/callisto.dom/log/access In this configuration, two Web sites, europa.domand callisto.dom, are being hosted on the same IP address: 192.168.1.2. After a request comes to the IP address, Apache uses the Host:parameter and the ServerNameparameter of each of the virtual host definitions to determine the definition to which this request should be sent. The only configuration that must be specified in order to use name-based virtual hosting is to set up DNS settings for each of the FQDNs to be hosted so that the client can resolve the IP addresses correctly. Compare this to IP-based virtual hosting, whereby each of the IP addresses also had to be configured on the network interfaces of the machine. You can even do name-based virtual hosts with the different sites running on different ports on the same IP address as shown: Listen 80 Listen 8000 … NameVirtualHost 192.168.1.2:80 NameVirtualHost 192.168.1.2:8000 ServerName europa.dom DocumentRoot /home/websites/europa.dom/web ServerAdmin support@europa.dom ErrorLog /home/websites/europa.dom/log/error TransferLog /home/websites/europa.dom/log/access (continued)

For high quality website hosting services please check tomcat web hosting website.

Chapter 15: Shared Tomcat Hosting . The FQDN of the Web site can be used in place of the IP address in the directive. In this case, there should not be any problems in the DNS resolution of the host names in the machine. This is because when Apache starts up, it resolves each of the FQDNs in its directives to their IP addresses before offering the Web service. Problems in resolving these addresses (for example, when a DNS server cannot be reached in time) during startup can cause Apache to abort prematurely. Name-Based Virtual Hosting in Apache While IP-based virtual hosts help maximize the use of resources, they are still not feasible in places where hundreds of domains must be hosted on the same machine. Obtaining one IP address for each host or configuring many network interfaces on the same machine becomes a logistical nightmare. In these cases, name-based virtual hosting can be used. Name-based virtual hosting depends solely on an extension to the HTTP protocol. In an HTTP 1.0 protocol, a Web client or a browser merely had to make a TCP connection to port 80 of a Web server and request a document using a relative location identifier in order for the Web resource to be fetched. For example, to access the document http://europa.dom/index.html, the browser could look up the IP address of europa.dom, make a TCP connection to port 80 of the IP address, and get the complete resource just by using the HTTP GET command, as shown here: $ telnet 192.168.1.2 80 Trying 192.168.1.2… Connected to 192.168.1.2. Escape character is ^] . GET /index.html HTTP/1.0 The response from the server would look as follows: HTTP/1.1 200 OK Date: Fri, 23 Feb 2007 07:38:44 GMT Server: Apache/2.2.4 (Unix) mod_jk/1.2.20 Last-Modified: Fri, 23 Feb 2007 05:54:33 GMT ETag: 10c07d-93-6d00d840 Accept-Ranges: bytes Content-Length: 147 Connection: close Content-Type: text/html [… Rest of the contents of index.html] However, this enables only one Web site to be accessed per IP address; otherwise, it would be impossible to discover the host for which the request was intended. To tackle this problem, the Host: header, as introduced in HTTP 1.1, is used to determine the Web site from which the resource is requested. This header has been implemented by many HTTP 1.0 clients, too. With this new header, the HTTP headers exchanged between an HTTP/1.1-compliant Web client and a server would look like the following from the client: GET /index.html HTTP/1.0 Host: europa.dom

If you looking for unlimited one inclusive web hosting plan please check web hosting plan website.

Chapter 15: Shared Tomcat Hosting The two IP addresses used in the directives should belong to network interfaces for the machine on which Apache would be running. You may have noticed that each of the Web sites has its own document root and its own log files for access and error logging. Various other directives can be placed in these virtual host definitions to enable further customization. Omitting these other directives would cause the virtual host to inherit any values from the global settings in the configuration file. Testing Your Configuration Finally, the following summarizes the steps you need to take to configure IP-based virtual hosting on Apache: 1. Make DNS changes, or edit the host file for the hosts that you wish to run Apache on. For IP-based virtual hosting, each host must have a unique IP address. You can use the ifconfig command to add a virtual interface if your machine does not have multiple network cards. 2. Edit Apache s httpd.confconfiguration file and add Listen directives for each of the virtual hosts, as shown in the previous section. Remove the existing Listen directive that listens on all network interfaces. 3. Edit the httpd.confconfiguration file and add VirtualHostsections for each of the virtual hosts, as shown in the previous section. 4. Make sure that the DocumentRootin each VirtualHostsection points to the location of the Web site content for the virtual host. 5. Restart Apache using the apachectlcommand. You should now be able to start your browser and view the respective Web sites. You can do this by either using the host names of the Web sites ( http://callisto.dom, http://europa.dom) or even the IP addresses ( http://192.168.1.2, http://192.168.1.20). Avoiding Common Mistakes Some common mistakes to avoid include the following: . Apache, in its default configuration, starts up and listens on all the configured network interfaces on the machine. If, for some reason, Apache is configured to listen on only a restricted number of IP addresses on the machine (using the Listen directive), it is important to ensure that Apache is listening on all the IP addresses of the various IP-based virtual hosts in order for all of them to work. . Using any random combination of IP addresses and Web host names will not always work as expected. This is commonly done by configuring the client machine to use a Domain Name Service (DNS) server. The Web client would query this DNS server for the IP address of the given host name, and then use the IP address returned by the DNS server to connect to the Web server. Similarly, the Web server would expect requests for the host name at the IP address specified in the corresponding NameVirtualHostdirective. . Needless to say, if the IP address given in the NameVirtualHost directive doesn t match the one returned by the DNS server for the host name, the Web client and the server won t be able to talk to each other.

If you looking for unlimited one inclusive web hosting plan please check cheap web hosting website.

Chapter 15: Shared Tomcat Hosting For example, on Linux, using the ifconfig command adds a virtual interface and configures the NIC with an IP address at the same time. If an Ethernet interface named eth0 has already been configured, it is simple to add an aliased interface called eth0:1 (in Linux, virtual Ethernet interfaces are named with the syntax
:), using the following command: $ ifconfig eth0:1 netmask Configuring IP -Based Virtual Hosting in Apache Adding IP-based virtual hosts in Apache is trivial. Merely add a block to Apache s httpd.conf file for each corresponding Web site, and a few associated parameters. Let s look at a sample configuration: Listen 80 … ServerName europa.dom DocumentRoot /home/websites/europa.dom/web ServerAdmin support@europa.dom ErrorLog /home/websites/europa.dom/log/error TransferLog /home/websites/europa.dom/log/access ServerName callisto.dom DocumentRoot /home/websites/callisto.dom/web ServerAdmin support@callisto.dom ErrorLog /home/websites/callisto.dom/log/error TransferLog /home/websites/callisto.dom/log/access Here, two IP-based virtual hosts, europa.domand callisto.dom, are configured to run on the IP addresses 192.168.1.2and 192.168.1.20, respectively. The Listen directive listed in the beginning causes Apache to listen on port 80 on all network interfaces 192.168.1.2, 192.168.1.20, plus any others configured on this server machine. If you need to have it listen on specific network interface only, you can specify an IP address as a part of the directive as shown: Listen 192.168.1.2:80 Listen 192.168.1.20:80 In this example, Apache is configured to listen on port 80; this means it needs to be started as root. To be able to run Apache as non-root, change the port number to 1024. Each of the virtual hosts is defined in a section: . The ServerName directive sets the domain name to be served by this virtual host. . The DocumentRoot directive points to the base directory to be used for serving pages for this domain. . The ServerAdmin directive lists the e-mail address of the Web server administration personnel. . TransferLogand ErrorLog point to the log files to be used for Web site access and Web site error messages, respectively.

If you looking for unlimited one inclusive web hosting plan please check web hosting plan website.

Chapter 15: Shared Tomcat Hosting For the purposes of providing a simple test example, create a sample HTML page named index.htmlin the document root of each of these domains. For example, the file /home/websites/europa.dom/web/ index.htmlshould contain the following HTML: Welcome to Europa.dom s Apache hosted website Create a similar file as /home/websites/callisto.dom/web/index.html, and change europa.dom to callisto.dom. You also need to ensure that the domains europa.domand callisto.dom can be resolved by the client and the server machines. This should be done by setting up your DNS server entries for these hosts. DNS configuration is not covered in this chapter, although for testing purposes, you can edit the hosts file on the server and client machine, as shown, to get the same effect: For name-based virtual hosting, set europa.domand callisto.dom to the same IP address (here 192.168.1.2), and add the following line to your hosts file: 192.168.1.2 callisto.dom europa.dom For the IP-based virtual hosting example, change this so that the domains have different IP addresses (here 192.168.1.2 and 192.168.1.20): 192.168.1.2 callisto.dom 192.168.1.20 europa.dom Naturally, these need to be valid IP addresses for the server machine. The next section explains how you can get another IP address when your server machine has just one network card. IP -Based Virtual Hosting in Apache In IP-based virtual hosting, a machine is configured to have a number of IP addresses equal to the number of hosts it will serve. Therefore, a machine that is to host ten Web sites would need ten IP addresses configured. These additional IP addresses may be configured either by adding physical network interfaces (NICs) network cards to the machine, or, as is more common, by adding aliased network interfaces to the computer. Normally, when an NIC is added to a machine, it is configured with a single IP address, which is used by various services. However, it is possible to configure the same NIC with more than one IP address. Adding these additional IP addresses involves using operating system specific commands for first creating a virtual interface and then configuring it with a virtual IP address. This process normally involves using a physical NIC and adding virtual interfaces on top of it, a process also commonly known as aliasing.

For high quality jboss hosting services please check jboss web hosting website.

Chapter 15: Shared Tomcat Hosting newsletter, whose FQDNs would be p2p.wrox.comand newsletter.wrox.com. However, because the distinction between an FQDN and a domain name is not relevant in this discussion, the terms are used interchangeably. Typically there are two ways in which virtual hosting is implemented: IP-based virtual hosting and name- based virtual hosting. . IP-based virtual hosting: In this mechanism, each Web site domain needs to have a different IP address. The Web server listens to each of these network interfaces, and serves resources from the relevant domain based on the IP address. . Name-based virtual hosting: The Web site domains can share an IP address, and the Web server determines which domain the request is for based on the HTTP request headers. Each of these mechanisms has advantages and disadvantages. IP-based virtual hosting requires either multihoming hosts machines with multiple network interface cards (NICs) or setting up virtual network interfaces. This often runs into limits, and besides IP addresses are a scare resource. Name-based virtual hosting overcomes these issues, but has its own set of limitations. For instance, SSL requires unique IP addresses, so secure Web sites cannot use name-based virtual hosting. Also, some really, really old browsers don t support sending the extra HTTP request header information required to support name-based virtual hosting. Virtual Hosting in Apache This section covers how IP- and name-based virtual hosting is configured in the Apache HTTP server. A common configuration for Web deployments is to have Apache serve up requests for static resources (HTML pages, images, multimedia), and have Tomcat handle requests for JSPs and servlets. In such environments, it is important to understand how Apache is configured for virtual hosting. It should be noted that the choice of IP or name-based virtual hosting is not an either-or choice: Apache is quite capable of supporting both of these in the same configuration. Example Deployment Scenario Before you continue configuring Apache for virtual hosting, look at the example deployment scenario that will be used in the rest of the chapter. This section covers configuring Apache to serve two fictitious virtual hosts: europa.domand callisto .dom on the same Apache instance. To ensure that these domains are really fictitious, we have even chosen a fictitious TLD (top level domain) name dom. In this example, we add our own DNS entries for the virtual hosts, so using a fictitious TLD is not a problem. Naturally, these virtual hosts will be running on the same IP address for name-based virtual hosting, and on different IP addresses for IP-based virtual hosting. Each of the domains would have its own document root in / home/websites//web.

For high quality website hosting services please check cheap web hosting website.

Shared Tomcat Hosting Many small businesses do not need, or cannot afford, the cost of running a Web site hosted on a dedicated server or a cluster of servers, and hiring IT engineers to maintain them. A common solution for these businesses is to use a hosting service provided by an Internet Hosting Service Provider. Typically, these hosting services are shared hosting situations in which multiple Web sites can be running on a single computer. Running more than one Web site on one computer is called virtual hosting. These hosting services allow for the sharing of resources such as the Web server, database server, mail server, firewall, and so on. Thus, all the services that are typically used in this scenario must have built-in support for shared hosting. The following shared hosting topics are covered in this chapter: . An introduction to virtual hosting terminology . Virtual hosting using the Apache HTTP server . Virtual hosting using Tomcat in both a standalone configuration, as well as with the Apache HTTP server . Options for tuning Tomcat resource usage in a shared hosting situation Apache 2.2, Tomcat 6, and mod_jk are used for all of the examples in this chapter. Virtual Hosting Concepts In this chapter, the term Web site refers to the contents of a distinct Fully Qualified Domain Name (FQDN), which is served by a Web server. Strictly, a FQDN consists of two parts: a host name and a domain name. For example, the FQDN www.wrox.comconsists of the host name www and the domain name wrox.com .The domain name wrox.com has other hosts such as p2pand

For high quality java hosting services please check tomcat web hosting website.