It’s Tuesday. (I think…)

It’s Tuesday. Or at least I think it is, if I’m doing the math right.

It’s one of the things I most relish about our now-traditional week of Thanksgiving on the Oregon coast: the blessing of losing track of time and date, surrounded by family, and the calming influence of sand and waves and salt air.

Ian at Cape Kiwanda, OR
Ian at Cape Kiwanda, OR (November 2018)

Tomcat: Enabling SSI

This is the fifth in my series detailing my efforts to stand up a Tomcat/ACF10 development environment next to my existing Apache/JRun/ACF9 stack. For background, see the first post in the series.

Enabling Tomcat’s ability to process server-side includes (SSI) requires changes to two configuration files. File ./cfusion/runtime/conf/web.xml contains definitions for both a filter and a servlet for processing SSI’s, as well as a pair of corresponding servlet-mapping and filter-mapping definitions for filenames matching the *.shtml pattern. Uncomment either the filter or the servlet element (but not both), and the corresponding -mapping element. Modify the -mapping element based on the naming conventions you use and/or add additional -mapping elements, as needed.

If you decide to go the filter route on this, you should also note that the default web.xml file’s definition of the filter determines whether to run files through the SSI processing based on the MIME-type of the file. You will almost certainly have to also uncomment, and possibly supplement, the entry/entries in the MIME-type mappings in the same file.

The second file that requires a tweak, per the Tomcat SSI How-To, is ./cfusion/runtime/conf/server.xml. As noted in the docs, only contexts configured as “privileged” can use the SSI capabilities. Add the privileged="true" attribute to Context element for the ColdFusion context:


Throw together a quick test SSI file, bounce your server, and verify that it works.

I clearly have some additional homework to do on this one, as I dont yet understand the benefits and drawbacks of the filter-vs-servlet choice above. More to come on that.

Tomcat: Configuring Access Logging

This is third in my series of posts detailing my efforts to stand up a Tomcat/ACF10 development environment next to my existing Apache/JRun/ACF9 stack. For background, see the first post in the series.

Access logging in Tomcat is fairly straightforward to set up, and the official docs are very understandable. The default configuration installed with ACF10 includes an entry for access logging in ./cfusion/runtime/conf/server.xml. Toward the bottom of the file, find the <Host> element and its child access log <Valve> element.

<Host name="localhost" ... >

Most of what’s shown there is easy to understand. A couple of items are worth touching on:

  • the pattern attribute specifies what gets logged for each request; as noted in the docs “common” and “combined” are short-cuts for standard sequences of commonly-used field
  • the fileDatePattern attribute is used to specify the naming mask for the log file; it also specifies the frequency at which the log files are rotated if the logs are specified as being rotatable. Where this mask goes to the day level, access logs will be specified each day.
  • I’ve temporarily set up the access logs to be created in the /tmp folder just for convenience as I work through configuring; I will change this to have the logs created in a more standard (and more secure) location as I get closer to wrapping this up.

Configure your logs as needed, restart the server, bounce a couple requests off it, and verify that the access logs are present and functional.