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.
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, it's a good idea to test configuring with Resin standalone.
Each virtual host has its own host block. At very least, each host will define the specifying the host name and an to specify the document root.
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/docs/test.jsp.
Browsing http://slytherin.caucho.com/test.jsp will look for /home/www/slytherin/docs/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 and AddModule must appear before the CauchoConfigFile for Apache to properly understand the CauchoConfigFile command. If they're missing, Apache will send an error.
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 user needs a separate JVM. In this configuration, each JVM needs its own srun-port and possibly its own srun-host.
In the most straightforward configuration, each JVM gets its own resin.conf. The resin.conf can use resin:include to share common configuration.
Here's the corresponding gryffindor.conf
You'll start each JVM separately. With Unix, you might do something like:
On Unix, thewill let know which server to stop.
When you restart the web server, you can look atand to check your configuration. Check that each virtual host is using the and that you expect.
Why the host is necessary
The <host> block in gryffindor.conf and slytherin.conf is required for a subtle reason. When Resin compiles JSP files, it generates a Java class name. Classes for different hosts get different class names to prevent name collisions.
If gryffindor.conf and slytherin.conf omit the <host>, Resin will generate the same class name for both hosts. If both hosts also use the same work-dir, one host will see the JSP for the other host.
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.