virtual hosting

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.

Virtual Host Concepts

A "virtual host" has a unique domain name, but the same ip
address 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".

Testing 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, developers 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.

Standalone Virtual Hosting

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 id 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.

JVM per virtual 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.

Back-end JVM's

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.

Resin front-end

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.

When you restart the Apache web server, you can look at
http://gryffindor/caucho-status
and http://slytherin/caucho-status to check
your configuration. Check that each virtual host is using the
srun-host and srun-port that you expect.

IP-Based Virtual Hosting

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.

Internationalization

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.

Virtual Hosts with Apache or IIS

A common configuration uses virtual hosts with Apache or IIS.
As usual, Apache or IIS will pass matching requests to Resin.

Apache

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.

The ServerName directive in Apache is vital to make Resin's
virtual hosting work. When Apache passes the request to Resin, it
tells Resin the ServerName. Without the ServerName,
Resin can get very confused which host to serve.

Cloud-optimized Resin Server is a Java EE certified Java Application Server, and Web Server, and Distributed Cache Server (Memcached).Leading companies worldwide with demand for reliability and high performance web applications including SalesForce.com, CNET, DZone and many more are powered by Resin.