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.

This entry was posted on Wednesday, September 23rd, 2009 at 8:28 pm and is filed under tomcat. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.