Tomcat: Directory Aliases

In this next post within my series of short posts covering different aspects of configuring Tomcat to get a Tomcat/ACF10 development environment working, we look at setting up directory aliases to provide some of the same capabilities as Apache httpd’s Alias and AliasMatch directives.

This is the next in my series of short posts related to configuring Tomcat, as I work on getting a Tomcat/ACF10 development environment stood up next to my existing Apache/JRun/ACF9 application stack. See the first post in the series for a bit of background.

We’ll look here at how to set up directory “aliases” in Tomcat, providing something equivalent to Apache httpd’s Alias and AliasMatch directives. In my current Apache setup, I use several such directives to make shared folders appear as if they were local folders in similar locations across multiple apps. Back in the first post of this series, I touched on our directory structure and how those folders appear within the applications; I’ll summarize that here again:

  • appGroup1
    • common
    • app1a (http://localhost/app1a/)
    • app1b (http://localhost/appab/)
    • app1c (http://localhost/app1c/)
  • appGroup2
    • common
    • app2a (http://localhost/app2a/)
    • app2b (http://localhost/app2b/)
    • app2n (http://localhost/app2n/)
  • app3 (http://localhost/app3/)
  • shared

Within each of the application groups “appGroup1” and “appGroup2”, the “common” folder contains assets shared by the applications in the corresponding group; this folder is aliased into each of the individual applications within the group to appear as if it were nested below the application folder (e.g., http://localhost/app1a/common, http://localhost/app1b/common). All of the applications reference the “shared” folder as a root level folder “/shared” (i.e., as http://localhost/shared).

One way to implement this in Tomcat is via the aliases attribute of the Context element in file ./cfusion/runtime/conf/server.xml. The server.xml file created as part of installing ACF10 has a Context element within the Host element for “localhost”, but it is commented out (relying on default values for the relevant attributes). Uncomment that element and add the needed aliases. Aliases are specified as a comma-delimited list of a=b pairs, where “a” is a virtual path and “b” is the path to which requests to “a” are to be mapped.

As an example based on our needs above, we need URL requests to /shared to be mapped to directory /[path to]/shared, so the alias for that virtual directory would be specified as /shared=/[path to]/shared.

Per the Tomcat docs, the alias path “a” must start with a leading “/”, and the directory to which it is mapped must be an absolute path (also beginning with a leading “/”). Tomcat then searches for requested resources within the first virtual directory where the specified alias matches the path. For our examples above, then, well need to set up several aliases:

  • /shared=/[path to]/shared
  • /app1a=/[path to]/appGroup1/app1a
  • /app1a/common=/[path to]/appGroup1/common

Aliases analogous to the second and third above, would be set up for each of the applications within each application group. In my playing with this so far, Tomcat doesn’t seem to care which of those second and third entries in the above list comes first, using the most specific alias. Putting all of that together then, we’d end up with something like this:

   aliases="/shared=/[path to]/shared,/app1a=/[path to]/appGroup1/app1a,/app1a/common=/[path to]/appGroup1/common"

Make the needed configuration changes, bounce your server, and throw together a quick file to verify that resources are being retrieved as expected.

A couple final notes on this:

  1. This is a really quick-and-dirty way to include a folder from a user’s home directory as a location Web documents can be retrieved from. Just set up an alias like /~ron=/Users/ron/Sites and you’re there. Note that this doesn’t get you to the point where Java Web apps can be served from home directories; we’ll look into that in another post.
  2. There are other possibly better ways to accomplish this same end result (e.g.,. with a separate Context for each application). We’ll look into some of that in a future post, as well.