Configuring Railo for the application server - Part 2

June 26, 2009 · By Gert Franz · 4 Comments

I am Continuing my blog related to the config settings in Resin and I would like to complete the explanation about the app-default.xml file and discuss the resin.conf file.

Defining welcome files and extension mappings

In the first part I showed you how to configure the CFMLServlet that is Railo. Now even though we have configured it, it still wont work since a call of a .cf* page would still display the source code of the file. So what we need to add is the following: <servlet-mapping url-pattern="*.cfm" servlet-name="CFMLServlet"/>
<servlet-mapping url-pattern="*.cfml" servlet-name="CFMLServlet"/>
<servlet-mapping url-pattern="*.cfc" servlet-name="CFMLServlet"/>
<servlet-mapping url-pattern="*.cfm/*" servlet-name="CFMLServlet"/>
<servlet-mapping url-pattern="*.cfml/*" servlet-name="CFMLServlet"/>
<servlet-mapping url-pattern="*.cfc/*" servlet-name="CFMLServlet"/>
<servlet-mapping url-pattern="/flashservices/gateway/*" servlet-name="AMFServlet"/>

These servlet mappings map a certain extension or pattern in the URL to a certain servlet. The CFMLServlet is called whenever a file that matches *.cfm, *.cfml, *.cfc, *.cfm/*, *.cfml/*, *.cfc/* is called. So you can see that SES type URL's are working as well.
Other application servers like Jetty or Tomcat need to rely on URL rewriting in order to accomplish the same behavior. In addition you can see that the AMFServlet is invoked for every call to /flashservices/gateway/*. In this section you could eventually outcomment the .php or .jsp calls in Resin.

Welcome files

Files that are called implicitly called when a directory is called over the url are defined in the <welcome-file-list> section. It looks like this: <welcome-file-list>
<welcome-file>index.cfm</welcome-file>
<welcome-file>index.html</welcome-file>
</welcome-file-list>

Again here you can exclude .php or .jsp, or include them :-). resin.conf
The resin.conf file is used to configure the application server. It is important to know that this is not a detailled description of it. There is much more information on the official related Caucho Resin 3.1 documentation. I want to concentrate on the most important things here.

class-loader

This section defines where the global JAR files are located. If you want to keep your installation clean then it is advisable to use the default path for this (valid in Resin 3.1.9) called ${resin.home}/ext-lib.
Then you can update Resin and have the libraries in a separate place. Please note that if you place the Railo JAR's in here the railo-server directory will be located below this directory.

dependency-check-interval <dependency-check-interval>2s</dependency-check-interval> This interval defines how often the Resin server will look for a change in the resin.conf. Please note that the server will be restarted if there is a change in the configuration and therefore all existing sessions will be lost. Normally you should set this setting to a very high number.

http
<http address="*" port="8600"/> The http port here is the port for the integrated web server in Resin. Caucho claims it to be faster than Apache. But I only use it for development and not for production. It is important to know that this is just the web interface for it. So the actuall processing of CFML pages happens on port 6800 normally.

JVM arguments
Further below the http definition, you'll find the different JVM arguments. <!--
- The JVM arguments
<jvm-arg>-server</jvm-arg> -->
<jvm-arg>-Xms256m</jvm-arg>
<jvm-arg>-Xmx256m</jvm-arg>
<jvm-arg>-Xss2m</jvm-arg>
<jvm-arg>-XX:MaxPermSize=128m</jvm-arg>
<jvm-arg>-Xdebug</jvm-arg>
<jvm-arg>-Dcom.sun.management.jmxremote</jvm-arg>

I normally play around with the Xms and Xmx definitions here. You can adapt them as you like. Please note that by default the server uses the client JRE. You can easily use a server JRE if you add the corresponding argument.

Resin Threads
<!-- Maximum number of threads. -->
<thread-max>256</thread-max>

Here you can define how many parallel requests could be handled by Railo. There will be some changes to this in Railo so that you can set this in the Railo admin. But more to come on this soon.

Server definition
<!-- define the servers in the cluster -->
<server id="" address="127.0.0.1" port="6800"/>

Here you define which servers are running in the cluster. If you have several instances of Railo running you need to name the instances and place them on either different IP addresses or ports. Then you only need to start the corresponding server by using the name argument for the httpd.exe file (or in the windows service definition).

virtual host definition
The different hosts that create web contexts can be defined with the host tag in Resin. I will display three common definitions for virtual hosts and then explain them in detail: <!-- configures the default host, matching any host name -->
<host id="" root-directory="d:/">
<!-- - configures an explicit root web-app -->
<web-app id="/" root-directory="projects"/>
</host>

This entry defines the default host. So if a virtual host reaches this server and it cannot be found in any <host> definition this virtual host definition will be invoked. So by default my web calls land in the folder d:/projects.

<host id="getrailo.local" root-directory="D:/projects">
<host-alias>getrailo.com.local</host-alias>
<host-alias>getrailo.org.local</host-alias>
<web-app id="/" root-directory="getrailo.local" />
</host>
This definition defines the virtual host called getrailo.local and mapps it to the folder d:/projects/getrailo.local. In addition two other host aliasses are routing the requests to this directory.

<host regexp="(.+)">
<host-name>${host.regexp[1]}</host-name>
<root-directory>D:/projects/${host.regexp[1]}</root-directory>
<web-app id="/" document-directory="."/>
</host>
The last example defines an implicit virtual host context. So if a certain host name reaches the server, and the corresponding directory in d:/projects which is called exactly as the virtual host, the web context will be used in this location. If the web context hasn't existed at that time it will be created and populated with the necessary Railo files.

There are some more sophisticated ways of how to configure Railo with Resin. If you have any question or you need assistance on how to configure Railo with your application server, just contact us for our services.

Tags: Configuration · HowTo · Railo 3.1

4 responses so far ↓

  • 1 Jamie Krug // Jun 27, 2009 at 3:14 AM

    &quot;So you can see that SES type URL's are working as well. Other application servers like Jetty or Tomcat need to rely on URL rewriting in order to accomplish the same behavior.&quot;

    This is not true for Tomcat. In Tomcat's web.xml (or in an EAR/WAR configuration) simply set a Railo servlet-mapping with the url-pattern /index.cfm/* as follows:

    &lt;servlet-mapping&gt;
    &lt;servlet-name&gt;GlobalCFMLServlet&lt;/servlet-name&gt;
    &lt;url-pattern&gt;/index.cfm/*&lt;/url-pattern&gt;
    &lt;/servlet-mapping&gt;

    This is not quite as broad as the URL pattern used in the Resin example above, but it just means you might need a couple more servlet-mapping patterns. For example, if you have an app running at a root index.cfm as well as a blog at /blog/index.cfm you'll want to add another servlet-mapping for url-pattern /blog/index.cfm/*

    I can't seem to find the description of how url-pattern stuff is processed in Tomcat, but I just read something that makes me think index.cfm/* might work for both (without the leading slash). I do know that *.cfm/* will NOT work, due to the interpretation of the * character in Tomcat url-pattern.
  • 2 Jamie Krug // Jun 29, 2009 at 5:04 PM

    Okay, regarding my prior comment on Tomcat url-mapping, the Java Servlet Specification explains why *.cfm/* won't work, but *.cfm and /index.cfm/* will...

    * A string beginning with a '/' character and ending with a '/*' suffix is used for path mapping.
    * A string beginning with a '*.' prefix is used as an extension mapping.
    * A string containing only the '/' character indicates the &quot;default&quot; servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
    * All other strings are used for exact matches only.
  • 3 Sean Corfield // Jul 1, 2009 at 5:05 AM

    Just wanted to confirm that this works beautifully - thank you Jamie! It has simplified my Apache configuration and removed the need for my ?path_info= workaround.

    Pretty much every CFML site I work on uses /index.cfm or /blog/index.cfm or /default/index.cfm so I only need three Servlet mappings.
  • 4 Jamie Krug // Jul 1, 2009 at 3:30 PM

    @Sean: Glad to hear. A single servlet mapping with more coverage would be nice, but like you, I generally need only one or two. Cheers.

Leave a Comment

Leave this field empty: