virtual-host.xtp

RESIN 3.2 最新源码

    <host id="www.gryffindor.com">
  
      <root-directory>/var/www/gryffindor</root-directory>

    </host>
  </cluster>

  <cluster id="slytherin">
    <server id="slytherin" host="localhost" port="6801"/>

    <host id="www.slytherin.com">
  
      <root-directory>/var/www/slytherin</root-directory>

    </host>
  </cluster>

  <cluster id="web-tier">
    <!-- see below -->
    ...
  </cluster>

</resin>
</example>

<p>Each back-end server is started separately:</p>

<example title="Example: starting backend servers">
unix&gt; java -jar lib/resin.jar -server gryffindor start
unix&gt; java -jar lib/resin.jar -server slytherin start
</example>

<example title="Example: stopping backend servers">
unix&gt; java -jar lib/resin.jar -server gryffindor stop
unix&gt; java -jar lib/resin.jar -server slytherin stop
</example>
</s2>

<s2 title="Resin web-tier load balancer">

<p>The host-specific back-end servers are ready to receive requests on their srun
ports.  A third Resin server can be used as the front-end load-balancer.
It receives all requests and dispatches to the back-end servers.</p>

<figure src="config-jvmpervirtualhost-resin.png" width="481" height="145"/>

<p>The Resin web server is configured using <a href="rewrite-tags.xtp">&lt;rewrite-dispatch></a> with a <a href="rewrite-tags.xtp#load-balance">&lt;load-balance</a> directive to dispatch to the back-end server.  A cluster is
defined for each back-end host, so that the
&lt;load-balance> knows how to find them.</p>

<example title="Example: /etc/resin/resin.xml for front-end web server">
&lt;resin xmlns="http://caucho.com/ns/resin"&gt;
  &lt;cluster id="web-tier"&gt;
    &lt;server-default>
      &lt;http port="80"/&gt;
    &lt;/server-default>

    &lt;server id="web" address="192.168.2.1" port="6800"/&gt;

    &lt;host id="gryffindor.com"&gt;
      &lt;web-app id="/"&gt;

        &lt;rewrite-dispatch>
          &lt;load-balance regexp="" cluster="gryffindor"/>
        &lt;rewrite-dispatch>

      &lt;/web-app>
    &lt;/host>

    &lt;host id="slytherin.com"&gt;
      &lt;web-app id="/"&gt;

        &lt;rewrite-dispatch>
          &lt;load-balance regexp="" cluster="slytherin"/>
        &lt;rewrite-dispatch>

      &lt;/web-app>
    &lt;/host>
  &lt;/cluster&gt;

  &lt;cluster id="gryffindor"&gt;
    &lt;server id="gryffindor" address="192.168.2.2" port="6800"/>

    &lt;host id="www.gryffindor.com">
      ...
    &lt;/host>
  &lt;/cluster&gt;

  &lt;cluster id="slytherin"&gt;
    &lt;server id="slytherin" address="192.168.2.2" port="6801"/>

    ...
  &lt;/cluster&gt;
&lt;/resin&gt;
</example>

<s3 title="Starting the servers on Unix">

<p>The front-end server JVM is started similar to the back-end JVMs:</p>

<example title="Example: starting the load balancer" >
unix&gt; java -jar lib/resin.jar -server web -conf conf/resin.xml start
...
unix&gt; java -jar lib/resin.jar -server web -conf conf/resin.xml stop
</example>

</s3> <!-- unix startup -->

<s3 title="Starting the servers on Windows">
<p>With Windows, each JVM is installed as a service.</p>

<example title="Example: installing as win32 service">
win&gt; resin.exe -install-as "Resin" -server resin -conf conf/resin.xml
win&gt; resin.exe -install-as "Resin www.gryffindor.com" -server gryffindor -conf conf/gryffindor.xml
win&gt; resin.exe -install-as "Resin www.slytherin.com"-server slytherin -conf conf/slytherin.xml
</example>

<p>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.</p>

<p>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.</p>

</s3> <!-- windows startup -->

</s2> <!-- resin frontend -->

</s1> <!-- jvm per virtual host -->

<s1 title="Configuration tasks">

<s2 title="host naming">

<p>The virtual host name can be configured by
an explicit <a href="host-tags.xtp#host-name">&lt;host-name></a>, 
a <a href="host-tags.xtp#host-alias">&lt;host-alias></a>,
a <a href="host-tags.xtp#host-alias-regexp">&lt;host-alias-regexp></a>,
by the <a href="host-tags.xtp#host">&lt;host></a> tag or 
implicitly by the <a href="host-tags.xtp#host-deploy">&lt;host-deploy></a>.
For explicit configuration styles, the host name and alias
configuration will generally be in the resin.xml.  For dynamic configuration,
the host aliases will typically be in an included <code>host.xml</code> inside
the host directory.</p>

<p>The default host catches all unmatches hosts.  Simpler sites will
use the default host for all requests, while security-conscious sites
may remove the default host entirely.  If the default host is not configured,
Resin will return a <code>404 Not Found</code>.</p>

</s2>

<s2 title="host.xml">

<p>The <code>host.xml</code> is an optional file where virtual hosts can
put host-common configuration.  The <code>host.xml</code>
is a good place for shared resources like authentication, database pools
or host-wide <a href="resin-ioc.xtp">beans and services</a>.  It's also a
location for the &lt;host-alias> in a dynamic hosting configuration.</p>

<p>The <code>host.xml</code> is configured in a &lt;host-deploy>
or &lt;host-default> by adding a
<a href="env-tags.xtp#import">&lt;resin:import></a> tag
specifying the host.xml name and location.  Because the &lt;host-default>
applies the &lt;resin:import> to every virtual host, it becomes a common
system-wide configuration file.</p>

</s2>

<s2 title="web-applications">

<p>Hosts must define <a href="webapp-tags.xtp">web-apps</a> in order to
serve files, servlets, or PHP pages.  If the host is missing all
webapps, Resin will return <code>404 Not Found</code> for all requests
make to the host.</p>

<p>Both explicit <a href="webapp-tags.xtp#web-app">&lt;web-app></a> and
dynamic <a href="webapp-tags.xtp#web-app-deploy">web-app-deploy</a> tags
are used to configure webapps.  The explicit style is generally used for
Apache-style configuration, while the dynamic style is generally used for
Java app-server .war configuration.</p>

<p>Remember, Resin's default servlets like the file, JSP, and PHP servlets
also need to be defined before they're used.  So all Resin configuration
files need to have a &lt;resin:import> of the <code>conf/app-default.xml</code>
configuration file either in the &lt;cluster> or in a
shared &lt;cluster-default>.  If the app-default.xml is missing, Resin will
not serve static files, JSP, or PHP, and will not even look in the
WEB-INF for resin-web.xml, classes, or lib.</p>

</s2>

</s1>


<s1 title="IP-Based Virtual Hosting">

<p>While Resin's virtual hosting is primarily aimed at named-based
virtual hosts, it's possible to run Resin with IP-Based virtual hosts.</p>

<p>With IP virtual hosting, each &lt;http&gt; block is configured
with the virtual host name.  This configuration will override any
virtual host supplied by the browser.</p>

<example>
&lt;resin xmlns="http://caucho.com/ns/resin">

&lt;cluster id="web-tier">
  &lt;server id="a"&gt;

    &lt;http address="192.168.0.1" port="80"
          virtual-host="slytherin.caucho.com"/&gt;

    &lt;http address="192.168.0.2" port="80"
          virtual-host="gryffindor.caucho.com"/&gt;

  &lt;/server>

  ...

  &lt;host id="slytherin.caucho.com"&gt;
    ...
  &lt;/host&gt;
&lt;/cluster&gt;
&lt;/resin&gt;
</example>

</s1>

<s1 title="Internationalization">

<p>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.</p>

<p>Support, of course, depends on the browser.  <a href="http://devedge.netscape.com/viewsource/2003/idn/">Mozilla 1.4</a> supports the encoding.

</p></s1>

<s1 title="Virtual Hosts with Apache or IIS">

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

<s2 title="Apache">
<p>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.</p>

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

<example title="httpd.conf">
LoadModule caucho_module /usr/local/apache/libexec/mod_caucho.so

ResinConfigServer localhost 6802

&lt;VirtualHost 127.0.0.1&gt;
  ServerName gryffindor.caucho.com
&lt;/VirtualHost&gt;

&lt;VirtualHost 192.168.0.1&gt;
  ServerName slytherin.caucho.com
&lt;/VirtualHost&gt;
</example>

<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.</note>
</s2>


<s2 title="Apache front-end">

<p>The host-specific back-end JVMs 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: </p>

<figure src="config-jvmpervirtualhost-apache.png" width="481" height="145"/>

<example title="httpd.conf">
&lt;VirtualHost 127.0.0.1&gt;
  ServerName gryffindor.caucho.com
  ResinConfigServer 192.168.0.10 6800
&lt;/VirtualHost&gt;

&lt;VirtualHost 192.168.0.1&gt;
  ServerName slytherin.caucho.com
  ResinConfigServer 192.168.0.11 6800
&lt;/VirtualHost&gt;
</example>

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

<s2 title="IIS">
<p>Configuration and installation for IIS virtual sites is discussed in the <a href="install-iis.xtp">IIS installation</a> section.</p>
</s2>
</s1> <!-- with Apache or IIS -->

<s1 title="Testing virtual hosts">
<p>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.  

</p><p>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.</p>

<p>Unix user's edit the file <code>/etc/hosts</code>:</p>

<example title="/etc/hosts">
127.0.0.1       localhost

127.0.0.1       www.gryffindor.com
127.0.0.1       www.slytherin.com
</example>
<p>Windows user edit the file <code>C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS</code>:</p>

<example title="C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS">
127.0.0.1       localhost

127.0.0.1       www.gryffindor.com
127.0.0.1       www.slytherin.com
</example>

</s1>


  </body>
</document>