Resin Documentationhome company docs
app server 
app server
<host>: virtual host configuration
Describes the virtual host configuration tags.
child of <cluster>,<host>,<web-app>
<access-log> configures the access log file. As a child of <web-app>, overrides the definition in the <host> that the web-app is deployed in. As a child of <host>, overrides the definition in the <server> that the host is in.
<access-log> schema
element access-log {
auto-flush?
& archive-format?
& auto-flush-time?
& exclude?
& format?
& path?
& rollover-count?
& rollover-period?
& rollover-size?
& init?
}
The default archive format is + ".%Y%m%d" or + ".%Y%m%d.%H" if rollover-period < 1 day. The access log formatting variables follow the Apache variables:
The default format is: default access log format
"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
allows for custom logging. Applications can extend a custom class from . Resin-IoC initialization can be used to set bean parameters in the custom class. Example: <access-log> in host configuration
<resin xmlns="http://caucho.com/ns/resin">
<cluster id="app-tier">
<host id="">
<access-log path='log/access.log'>
<rollover-period>2W</rollover-period>
</access-log>
</host>
</cluster>
</resin>
Example: custom access log
<resin xmlns="http://caucho.com/ns/resin">
<cluster id="app-tier">
<host id='foo.com'>
<access-log resin:type='test.MyLog'>
path='${resin.root}/foo/error.log'
rollover-period='1W'>
<init>
<foo>bar</foo>
</init>
</access-log>
...
</host>
</cluster>
</resin>
child of <host>,<web-app>
Specifies ear expansion. ear-deploy can be used in web-apps to define a subdirectory for ear expansion.
<ear-deploy> schema
element ear-deploy {
path
& archive-directory?
& ear-default?
& expand-cleanup-fileset?
& expand-directory?
& expand-path?
& expand-prefix?
& expand-suffix?
& lazy-init?
& redeploy-mode?
& require-file*
& url-prefix?
}
child of <cluster>,<host>,<webapp>
<error-page> defines a web page to be displayed when an error occurs outside of a web-app. Note, this is not a default error-page, i.e. if an error occurs inside of a <web-app>, the error-page for that web-app will be used instead. See webapp: error-page. child of <cluster>
<host> configures a virtual host. Virtual hosts must be configured explicitly.
Example: explicit host in resin.conf
<resin xmlns="http://caucho.com/ns/resin">
<cluster id="">
<host host-name="www.foo.com">
<host-alias>foo.com</host-alias>
<host-alias>web.foo.com</host-alias>
<root-directory>/opt/www/www.foo.com</root-directory>
<web-app id="/" document-directory="webapps/ROOT">
</web-app>
...
</host>
</cluster>
</resin>
Example: regexp host in resin.conf
<resin xmlns="http://caucho.com/ns/resin">
<cluster id="">
<host regexp="([^.]+)\.foo\.com">
<host-name>${host.regexp[1]}.foo.com</host-name>
<root-directory>/var/www/hosts/www.${host.regexp[1]}.com</root-directory>
...
</host>
</cluster>
</resin>
It is recommended that any <host> using a regexp include a <host-name> to set the canonical name for the host. <host-alias> defines a URL alias for matching HTTP requests. Any number of <host-alias> can be used for each alias. The host-alias can be used either in the resin.conf or in a host.xml when use host-deploy together with resin:import. <host-alias> schema
element host-alias {
string
}
Example: host-alias in the resin.conf
<resin xmlns="http://caucho.com">
<cluster id="">
<host id="www.foo.com" root-directory="/var/www/foo.com">
<host-alias>foo.com</host-alias>
<web-app id=""/>
</host>
</cluster>
</resin>
Since the <host-deploy> and <host> tags lets you add a host.xml file to customize configuration, the <host-alias> can also fit in the custom host.xml page. Example: host-alias in a /var/www/hosts/foo/host.xml <host xmlns="http://caucho.com"> <host-name>www.foo.com</host-name> <host-alias>foo.com</host-alias> <web-app id="" root-directory="htdocs"/> </host> <host-alias-regexp> defines a regular expression for matching URLs for a given virtual host. <host-alias-regexp> schema
element host-alias-regexp {
string
}
Example: host-alias-regexp in the resin.conf
<resin xmlns="http://caucho.com">
<cluster id="">
<host id="www.foo.com" root-directory="/var/www/foo.com">
<host-alias-regexp>.*foo.com</host-alias-regexp>
<web-app id=""/>
</host>
</cluster>
</resin>
child of <cluster>
<host-default> configures defaults for a virtual host. The host-default can contain any of the host configuration tags. It will be used as defaults for any virtual host. child of <cluster>
<host-deploy> configures an automatic deployment directory for virtual host.
<host-deploy> schema
element host-deploy {
archive-directory?
& expand-cleanup-fileset?
& expand-directory?
& host-default?
& host-name?
& path?
}
The following example configures as a host deployment directory. Each virtual host will have a directory for .war deployment. So the directory would serve the URL . <host-deploy>
<resin xmlns="http://caucho.com/ns/resin">
<cluster id="app-tier">
<root-directory>/var/www</root-directory>
<host-deploy path="hosts">
<host-default>
<resin:import path="host.xml" optional="true"/>
<web-app-deploy path="webapps"/>
</host-default>
</host-deploy>
</cluster>
</resin>
<host-name> defines the canonical name for a virtual host. The <host-name> will be used in Resin's logging, management, and is available in the host's variables. <host-host> schema
element host-name {
string
}
<redeploy-mode> configures the virtual-host's behavior when it detects changes in configuration files or classes. The <dependency-check-interval> controls how often the virtual host will check for updates.
<restart-mode> schema
element startup-mode {
string
}
child of <resin>,<cluster>,<host>,<web-app>
All Resource tags are available to the <host>, for example, resources like <database> or <authenticator>. Resources defined at the host level are available for all web-apps in the host. Example: shared database in host
<resin xmlns="http://caucho.com/ns/resin">
<cluster id="app-tier">
<server id="a" .../>
<host id="www.foo.com">
<database jndi-name="jdbc/test">
<driver type="org.postgresql.Driver">
<url>jdbc:postgresql://localhost/test</url>
<user>caucho</user>
</driver>
</database>
<web-app-default path="webapps"/>
</host>
</cluster>
</resin>
child of <cluster>,<host>,<web-app>
<rewrite-dispatch> defines a set of rewriting rules for dispatching and forwarding URLs. Applications can use these rules to redirect old URLs to their new replacements. See rewrite-dispatch for more details. rewrite-dispatch
<resin xmlns="http://caucho.com/ns/resin">
<cluster id="app-tier">
<host host-name="www.foo.com">
<rewrite-dispatch>
<redirect regexp="^/foo" target="/index.php?foo="/>
</rewrite-dispatch>
</host>
</cluster>
</resin>
<root-directory> configures the virtual host's filesystem root. Because the virtual host's root will typically contain non-public files like log files, all web-apps should have a path below the host. <root-directory> schema
element root-directory {
string
}
<secure-host-name> sets a host-name or URL to be used for secure redirection. For some security configurations, Resin needs to redirect from an insecure site to a secure one. The <secure-host-name> configures the host to redirect to. See Resin security. <secure-host-name> schema
element secure-host-name {
string
}
<startup-mode> configures the virtual-host's behavior on Resin startup, either "automatic", "lazy" or "manual".
<startup-mode> schema
element startup-mode {
string
}
child of <host>,<web-app>
<web-app> configures a web application.
When specified by , the application will be initialized on server start. When specified by , the application will be initialized at the first request. This means that servlets may start later than expected for applications. The following example creates a web-app for /apache using the Apache htdocs directory to serve pages. Example: custom web-app root <resin xmlns="http://caucho.com/ns/resin"> <cluster id="app-tier"> <host id=''> <web-app id='/apache' root-directory='/usr/local/apache/htdocs'> ... </host> </cluster> </resin> The following example sets the root web-app to the IIS root directory. Example: IIS root directory <resin xmlns="http://caucho.com/ns/resin"> <cluster id="app-tier"> <host id=''> <web-app id='/' root-directory='C:/inetpub/wwwroot'> </host> </cluster> </resin> When the is specified with a , can use replacement variables (). In the following, each user gets his or her own independent application using . Example: web-app root based on regexps
<resin xmlns="http://caucho.com/ns/resin">
<cluster id="app-tier">
<host id=''>
<web-app url-regexp='/~([^/]*)'
root-directory='/home/$1/public_html'>
...
</web-app>
</host>
</cluster>
</resin>
child of <cluster>,<host>,<web-app>
<web-app-default> configures common values for all web applications. child of <host>,<web-app>
Specifies war expansion. web-app-deploy can be used in web-apps to define a subdirectory for war expansion. The tutorials in the documentation use web-app-deploy to allow servlet/tutorial/helloworld to be an independent war file.
<web-app-deploy> schema
element web-app-deploy {
archive-directory?
& expand-cleanup-fileset?
& expand-directory?
& expand-prefix?
& expand-suffix?
& path?
& redeploy-check-interval?
& redeploy-mode?
& require-file*
& startup-mode?
& url-prefix?
& versioning?
& web-app-default*
& web-app*
}
Overriding web-app-deploy configurationThe web-app-deploy can override configuration for an expanded war with a matching <web-app> inside the <web-app-deploy>. The <document-directory> is used to match web-apps. Example: resin.conf overriding web.xml
<resin xmlns="http://caucho.com/ns/resin">
<cluster id="">
<host id="">
<web-app-deploy path="webapps">
<web-app context-path="/wiki"
document-directory="wiki">
<context-param database="jdbc/wiki">
</web-app>
</web-app-deploy>
</host>
</cluster>
</resin>
versioningThe versioning attribute of the <web-app-deploy> tag improves web-app version updates by enabling a graceful update of sessions. The web-apps are named with numeric suffixes, e.g. foo-10, foo-11, etc, and can be browsed as /foo. When a new version of the web-app is deployed, Resin continues to send current session requests to the previous web-app. New sessions go to the new web-app version. So users will not be aware of the application upgrade.
|