Each Resin instance can serve many virtual hosts. The virtual host will have its own servlets and documents. For greater isolation, you can configure each virtual host to have its own JVM and you can have all the virtual hosts controlled by a single web server.
A "virtual host" has a unique, but the same as other domain names. For example, www.gryffindor.com and www.slytherin.com can have the same ip address 192.168.0.13 and share the same web server.
In this scenario, both www.gryffindor.com and www.slytherin.com are registered with the standard domain name service registry as having the IP address 192.168.0.13. A user types in the url http://www.gryffindor.com/hello.jsp in their browser. The user's computer resolves the name www.gryffindor.com to the IP address 192.168.0.13. Resin is the webserver on the machine that has the IP address 192.168.0.13, so it receives the request. Resin determines which virtual host to use by looking at the request URL. Resin get's the from a HTTP header submitted by the browser.
Note: IIS, just to be different, uses the term "virtual sites" instead of "virtual hosts".
During development and testing, it is often inconvenient or impossible to use real virtual host names that are registered as internet sites, and resolve to an internet-available IP address. OS-level features on the test client machine can be used to map a virtual host name to an IP address.
For example, developer's often run the Resin server and the test client (usually a browser) on the same machine. The OS is configured to map the "www.gryffindor.com" and "www.slytherin.com" names to "127.0.0.1", pointing these host names back to computer that the client is running on.
Unix user's edit the file /etc/hosts:
Windows user edit the file C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS:
Configuring the standalone server is the easiest and best way of testing a virtual host configuration. The resin.conf is identical for Resin standalone and for Resin as a servlet runner. So even when using an external web server like Apache or IIS, it's a good idea to test configuring with Resin standalone.
Each virtual host has its own host block. At the very least, each host will define the specifying the host name and a root web-app. A <root-directory> is often used to provide a host specific root for logfiles.
The following sample configuration defines two virtual hosts, gryffindor and slytherin, each with its own document directory.
Browsing http://gryffindor.caucho.com/test.jsp will look for /home/www/gryffindor/webapps/ROOT/test.jsp.
Browsing http://slytherin.caucho.com/test.jsp will look for /home/www/slytherin/webapps/ROOT/test.jsp.
A common configuration uses virtual hosts with Apache or IIS. As usual, Apache or IIS will pass matching requests to Resin.
The Resin JVM configuration with Apache is identical to the standalone configuration. That similarity makes it easy to debug the Apache configuration by retreating to Resin standalone if needed.
Thedirective in Apache is vital to make Resin's virtual hosting work. When Apache passes the request to Resin, it tells Resin the . Without the , Resin can get very confused which host to serve.
Note: You'll the LoadModule must appear before the ResinConfigServer for Apache to properly understand the ResinConfigServer command. If they're missing, Apache will send an error.
Configuration and installation for IIS virtual sites is discussed in the IIS installation section.
Resin can be configured to deploy virtual hosts dynamically. Instead of adding a <host> tag to resin.conf, a directory on the file-system is established, and subdirectories become virtual hosts.
<host-deploy> is used in resin.conf:
Any directory created in $RESIN_HOME/hosts will now become a virtual host. You can also place a .jar file in $RESIN_HOME/hosts, it is expanded to become a virtual host.
Jar libraries and class files that are shared amongst all webapps in the host can be placed in lib and classes subdirectories of the host:
In some ISP setups, it may make sense to assign a JVM for each virtual host. The isolation of web-apps may not be sufficient; each host needs a separate JVM. In this configuration, each JVM needs its own srun-port and possibly its own srun-host.
The setup is similar to load-balancing . A front-end web server receives all requests, and is configured to dispath to back-end Resin JVM's that correspond to the host name.
In the most straightforward configuration, each host specific backend JVM gets its own resin.conf. The resin.conf can use resin:include to share common configuration.
In this example, the virtual hosts www.gryffindor.com and www.slytherin.com each get their own JVM. The first step is the configuration and startup of the back-end, host specific instances of Resin. The second step is the by the configuration of the front-end server that dispatches requests to the appropriate back-end JVM.
Each back-end JVM is started separately:
On Unix, thewill let httpd.sh know which server to stop:
The host-specific back-end JVM's are ready to receive requests on their srun ports. A third instance of Resin in a separate JVM can be used as the front-end server. It receives all requests and dispatches to the back-end servers.
The Resin web server is configured using the LoadBalanceServlet to dispatch to the back-end JVM's. A cluster is defined for each back-end JVM, so that the LoadBalanceServlet knows how to find them.
The front-end server JVM is started similar to the back-end JVM's:
A script that handles the syntax for all three is convenient, and provides the opportunity to automate more sophisticated startup:
With Windows, each JVM is installed as a service.
You will either need to reboot the machine or start the service from the Control Panel/Services panel to start the server. On a machine reboot, NT will automatically start the service.
There is a bug in many JDKs which cause the JDK to exit when the administrator logs out. JDK 1.4 and later can avoid that bug if the JDK is started with -Xrs.
The host-specific back-end JVM's are ready to receive requests on their srun ports. Apache is the front-end server, and is configured to dispatch to the appropriate back-end Resin JVM for the host:
When you restart the Apache web server, you can look atand to check your configuration. Check that each virtual host is using the and that you expect.
While Resin's virtual hosting is primarily aimed at named-based virtual hosts, it's possible to run Resin with IP-Based virtual hosts.
With IP virtual hosting, each <http> block is configured with the virtual host name. This configuration will override any virtual host supplied by the browser.
Resin's virtual hosting understands host names encoded using rfc3490 (Internationalizing Domain Names in Applications). This support should be transparent. Just specify the virtual host as usual, and Resin will translate the brower's encoded host name the unicode string.
Support, of course, depends on the browser. Mozilla 1.4 supports the encoding.