When used with another web server, Resin serves JSPs and Servlets and the other web server serves static content like html and images.
The web server plugins (mod_caucho and isapi_srun) have two main tasks:
Note: "mod_caucho" is used to mean all the plugins. All of the plugins work the same, so "mod_caucho" is just a shorthand for "mod_caucho and isapi_srun".
mod_caucho discovers its configuration by contacting the ResinConfigServer specified in the httpd.conf or resin.ini. The ResinConfigServer can be any Resin server. When a user requests a URL, mod_caucho uses the configuration it has determined from the ResinConfigServer to determine whether Resin or Apache should handle the request. That decision is based on the configuration in the ResinConfigServer's resin.conf.
servlet-mapping's url-pattern selects the URLs to pass to Resin. servlet-mapping and url-pattern are part of the Servlet 2.3 standard, so there are many references explaining how it works.
url-pattern can take one of four forms:
Note: mod_caucho does not understand regular expressions. If you put regular expressions in your resin.conf, mod_caucho will not send the request to Resin. Apache will handle the request itself.
If you want to use regular expressions in servlet-mapping, web-app, or hosts, you must use Apache-specific configuration to send the request to Resin. You can see this by looking at /caucho-status. /caucho-status will not display any regular expressions.
There are two special servlet-names which only affect the plugins:and .
will direct a request to Resin. The servlet engine itself will ignore the plugin_match directive. You can use plugin_match to direct an entire subtree to Resin, e.g. to workaround the regexp limitation, but allow Resin's other servlet-mapping directives to control which servlets are used.
keeps the request at on the web server. So you could create a directory where all documents, including JSPs are served by the web server.
web-apps collect servlets and JSP files into separate applications. All the servlet-mappings in a web-app apply only to the URL suffix.
In the following example, every URL starting with /prefix/url maps to the web-app. The servlet-mapping only applies to URLs matching the prefix.
In the exaple, mod_caucho will match any URL matching /prefix/url/*.foo. /prefix/url/bar.foo will match, but /test/bar.foo will not match.
Note: Resin standalone allows aattribute instead of an id. Because mod_caucho does not understand regexps, it will ignore any web-app with a attribute.
Note: web.xml files and war files are treated exactly the same as web-apps in the resin.conf.
For dispatching, a host block gathers a set of web-apps. Each host will match a different set of URLs, depending on the web-app configuration. The default host matches any host not matched by a specific rule.
As usual, /caucho-status will show the URLs matched for each host.
Note: mod_caucho does not understand the hostattribute. It will ignore all hosts using . To get around this, you can either configure Apache directly (see below), or configure the default host with the same set of servlet-mappings. Since mod_caucho will use the default host if no others match, it will send the right requests to Resin.
The special URLis invaluable in debugging Resin configurations. displays all the resin.conf patterns, so you can easily scan it to see which URLs mod_caucho is sending to Resin and which ones are handled by Apache.
You can configure Apache directly, instead of letting mod_caucho dispatch from the resin.conf file. If you use this method, you need to make sure you match the Apache configuration with the Resin configuration.
Note: This technique uses Apache-specific features, so it's not directly applicable to IIS or iPlanet.
Apache'sand directives send requests to Resin. The mod_caucho handler is .
Because Apache'sis external to mod_caucho, /caucho-status will not show any dispatching.