Resin configuration is based on thefile located in . It's XML-based, although it allows for some non-XML laziness like omitting quotes from attributes.
The application configuration is based on the Servlet 2.3 deployment descriptor.
The configuration file parses into a (key, value) structure. LISP fans will recognize it as similar to an A-list and Windows fans will recognize it as similar to the NT registry. Unlike either, though, multiple items with the same key are allowed.
Note: Because the internal format has less structure than XML does, you can use either an element-based configuration or an equivalent attribute-based configuration. You should use whichever configuration simplifies your maintenance. The following example uses the element-based configuration exclusively.
The Resin configuration file is based on XML. Theelement encapsulates the entire configuration file.
Each resin.conf contains a singleelement that contains the configuration for the web server and servlet engine. All configuration outside the is non-server specific. For example, debug logging configuration and Java compiler configuration belongs outside the element.
Despite its name,contains configuration for the standalone HTTP server and the servlet runner. In fact, you can listen to multiple HTTP and servlet runner ports in the name .
In the current version of Resin only allows a single.
configures the application directory, which contains the documents, the servlets, the bean classes, and some extra configuration files like web.xml and taglib.tld. For many, the app-dir is the most important configuration. For example, if you're using Apache or IIS, you'll change app-dir to point to the Apache htdocs or the IIS inetpub/wwwroot.
can be used in the http-server, as above, in the host and in the web-app. If unspecified, it defaults to the directory of the enclosing block.
The sample resin.conf in the distribution points to an app-dir. If you start Resin from the distribution, you can put a hello.jsp in and you'll view it from a browser using .
Application servlets and classes belong inand jars belong in . Resin will automatically reload a class placed in either location. External jars, for example a database driver, should be put in instead.
Thedirectory is hidden by the web server. So, it is not possible for a browser to look at anything in that directory.
Note: JNI. Because of the way Java handles JNI, you should place the Javaclasses outside the directories, putting them in or instead. That means you'll need to restart Resin when you change those classes, so you should only put the interface classes outside WEB-INF.
In Resin 2.0, you must specify each port and protocol for the web server. In the example, Resin will listen to port 8080 using the HTTP protocol.
Configurations using Resin as a servlet runner for another web server will use an srun tag to listen for the servlet runner.
Resin 2.0 allows multiple id attribute.and tags. A virtual host configuration might use separate tags for each IP interface on the server. A load balancing configuration will use several tags, each representing a different backend server, and selected by the
Theelement contains configuration for a virtual host. The virtual host with is the default virtual host. If Resin doesn't match any other host, it will use the configuration in the default virtual host. This example and most configurations will use the default virtual host.
To configure a virtual host, just copy the default app-dir for the new virtual host so it will use a different application directory than the default host.block and set the attribute to the host name. You'll probably want to set the
(web application) is the core of Resin's jsp and servlet configuration. Each application has its own class loader, ServletContext variable, and directory. web-app uses the same syntax as the servlet 2.3 deployment descriptor with a few optional extensions.
The web-app with app-dir. If unspecified, as in the example, it defaults to the path below the host's app-dir. A web-app starts in and the WEB-INF will be .is the default web application. It's a good idea not to go overboard in creating web-apps. Most sites should just use the single default. Each web-app has its own
Servlet configuration follows the Servlet 2.3 deployment descriptor configuration. The servlet tag assigns a name to a servlet and specifies its class. Servlets which need configuration will use init-param to configure servlet parameters.
To actually use a servlet, you'll need to add a servlet-mapping tag for each servlet.
Eachtag specifies a separate servlet instance. You can create several servlet instances, each with different init parameters and different names, by creating multiple tags.
Servlets and their supporting classes generally belong inor in a jar in . A servlet class would belong in . Resin will automatically reload the servlets when they change. You can put servlets and their classes in the system classpath, for example, , but they will not be reloaded automatically.
specifies the URLs that invoke a servlet. The longest match between the URL and all the entries will select the servlet. If none of the entries match, Resin will serve the URL as a static file.
With a web-server like Apache, the servlet-mapping entries determine which URLs belong to Resin and which belong to Apache. Any match belongs to Resin and a non-match will belong to Apache. You can use the specialURL to look at the mapping.
The url-pattern specifies the URLs to match. The four patterns in the Servlet specification are , , , and .
Thein the matches a in a . As a Resin extension, you can specify all the configuration in the itself, avoiding the double entry.