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
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.
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
<Host name="localhost" ... >
Most of what’s shown there is easy to understand. A couple of items are worth touching on:
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
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.
Observant readers will note that things look a little different around here, and there is actually more at work here than just a new coat of paint: new version of WordPress, new theme, new version of PHP under the hood. I’m not quite done reworking all of the plumbing and I still need to hang some pictures. Ping me via the comment-stream if you find breakage as I continue tweaking and tuning.