|By Charlie Arehart||
|January 31, 2003 12:00 AM EST||
There are a lot of powerful new integration points between CFMX and Java, but one that might benefit a lot of people - even those who don't know how to program in Java - is the ability to leverage servlet filters in CFMX.
A filter is a Java program that can be used to execute before and/or after your CF template. More than just running some code in advance, a filter can also manipulate the request (the HTTP stream) that is calling your template, and can change how, or even if, your template is run, or cause some other template or code to run first. It can also manipulate the output (the HTTP response) that your template generates.
ColdFusion MX can run servlet filters. You don't need to write them because some have already been written for servlet and JSP developers. Because ColdFusion MX runs atop a J2EE server, we can leverage these or even write our own filters if we want to.
In this article, I'll show you where to find some example filters and how to implement them in CFMX. You don't need to understand Java to use them. By the way, they work in both the Enterprise and Pro (as well as developer and trial) editions of CFMX, and also with the built-in Web server in CFMX and external Web servers like IIS and Apache.
How Do Filters Compare to Application.cfm?
Filters may sound very similar to the way Application.cfm (and OnRequestEnd.cfm) work. But a filter has many added benefits and is really quite different from those two traditional mechanisms in CF. Before getting into the details of filters, it may help to first contrast them to those more traditional approaches.
Most will know that Application.cfm and OnRequestEnd.cfm are templates that run before (and after, in the case of OnRequestEnd.cfm) a ColdFusion template is executed. They provide a means to effect some kind of pre-or post-processing in order to augment your template.
Some use them to add a test (such as security) before a template runs, or to create some data structure (perhaps persisted in the application scope) to be shared by many templates. Some even use them for creating headers (and footers), though that may get complicated if you have a template that should run without the headers or footers.
Some Challenges with Application.cfm/OnRequestEnd.cfm
One problem with the traditional CF approach is that there's no way to stop these two files from running for any one template, as might be desired when trying to use them for headers and footers. (Of course, using them for headers and footers may be an arguable approach, but it does point up a limitation with them.) Any time you run a CF template, CF looks to run any existing Application.cfm in the current or a parent directory, whichever it finds first. And if there's an OnRequestEnd.cfm in the same directory as the Application.cfm that's run, that will be executed at the conclusion of the named template.
You can't tell CF to not run these files if they exist. Some of the other challenges are:
So why should they get excited about servlet filters? What do they really add?
Where Filters Augment Traditional CF Approaches
Filters work differently from the traditional approach of automatically running Application.cfm and OnRequestEnd.cfm. For one thing, you have much greater control of when a filter is run. Through some configuration files built into CFMX, which we will see later, you map filters to a given URL pattern, so that they can be made to apply to:
- A single template
- All templates in a given directory and subdirectories
- All templates of a given file type
- All templates on the entire server
More important, because these are added declaratively through configuration files (rather than controlled by code in the template directories) you can also:
- Designate multiple URL patterns for a given filter
- Designate multiple filters to a given pattern
- Add/remove/modify filters without the templates knowing about it
- Apply changes to a filter across several applications
It's true that CF developers can do some of these things themselves in Application.cfm processing, but remember that they may already be written as servlet filters, thus saving you the development effort. Also, remember the greater flexibility in mapping filters to URLs.
What could a response (output) filter do? Again, this is just a short list of creative solutions that do exist or could be created to process the output of a template before returning it to the user:
- Log page execution time
- Localization (targeting output to a locale)
- Image conversion
- XML transformations of XML output
- Data compression (gzip)
Where Can I Find Them?
As for where you can find these already written, there are a few places including jsptags.com and servletsuite.com. There are surely more, but the latter has quite a few that might interest CFers, including:
Profiler filter (track execution times)
IP filter (access restriction, load balancing)
The Power of a Compression Filter
That last item in the list, a compression filter, may be the most compelling one for many and, I'll give a specific example of one as a demonstration of how all this works. A compression filter, also often called a Zip or gzip filter, is a tool that compresses the output of a Web page so that it generally takes up far less space when being sent from the server to the browser. The browser can then decompress the page and render it as usual to the end user.
CF pages are notorious for having excessive white space, so a compression filter can be a big win for us. The good news is that most browsers, even relatively old ones, can support decompression. A compression filter will determine if a browser can support compression by checking the HTTP header called accept-encoding (or in CF, you could test it with cgi.http_accept_encoding) before trying to compress the page. A smart one might also balance the size of the page being processed before trying to compress it, since compression does cost some CPU cycles on both the server (to compress) and the client (to decompress) page.
Still, for all but the most trivial page, compression is generally a good thing, and it's rather easily tested to confirm the savings. In some testing I did, it resulted in a 4:1 reduction in bandwidth (size of pages downloaded to the browser). For sites that pay for their bandwidth utilization (someone is always paying for it), or just for the speed improvement of sending "lighter" pages to the browser, compression is valuable.
(It's worth noting that both Apache and IIS offer their own forms of compression that, if implemented properly, will generally suffice to provide the benefits that compression can bring. But if they're not set up, or not set up properly, then a filter in CFMX may be a good way to go. In fact, I wonder if in the future Macromedia may build one in and make it more simply enabled via an Administrator setting. Until then, it's a good example of a filter.)
How to Implement a Filter in Three Easy Steps
It's incredibly easy to implement a filter. If you visit any of the pages mentioned here, you'll find explanations of the filters, the downloadable files, how to configure them, and maybe an example that might be written as a JSP page. Most don't even show that, because there's nothing necessarily specific about using a filter with either CF or a JSP page, for instance. You just associate the filter with a given URL, and the filter doesn't care what kind of page it's processing before or after.
The only clue that the filter is written in Java is that the downloadable files will likely refer to a JAR (Java Archive). But all you need to know is where to put that file and how to set up CFMX to map the filter to a URL. That's really all there is to it. Indeed, the explanations on the page will often be very similar if not identical to what you need in CFMX. There are just three simple steps. I'll walk you through implementing that gzip/compression filter.
Upon visiting the page that holds the filter, such as the last one for the gzip filter mentioned above at www.servletsuite.com/servlets/ipflt.htm, you'll find a link to the JAR file that needs to be downloaded and placed into the cfusionmx\wwwroot\WEB-INF\lib directory. It doesn't matter if you use another Web server or store your CF templates somewhere other than the cfusionmx\wwwroot. That directory will still exist, and under it you will find the WEB-INF\lib subdirectory. Place the file there. This is the location in which J2EE servers (like that underlying CFMX) expect to find Java programs like filters, when they are packaged as JAR files. (If you happened to get a filter or servlet that was just a "class" file, rather than a JAR, it would be placed in the cfusionmx\wwwroot\WEB-INF\classes directory.)
As the page showing the downloadable filter may also indicate, the next step is to modify the web.xml file to define a pointer and map to the filter. Again, this file does exist in CFMX, specifically in the cfusionmx\wwwroot\WEB-INF. The directions will likely indicate just the XML that you need to add to the web.xml file. In the case of the compression filter, it would be:
Note that in the next to last line, we're indicating that this filter should apply against all files of type "cfm", and since we don't say otherwise, it means all such files in all directories that are run under CFMX. You could create additional filter-mapping entries to list other URL mappings. To just control files in a "test" directory under your webroot, the pattern could be "/test/*.cfm" or simply "/test/*".
Of course, as when modifying any of the XML files in the CFMX configuration, be very careful. It may even be wise to save a backup of the file before editing it so that you can recover in case the server fails to start, etc.
The last step is to restart the server. CF will not detect the filter unless the server is restarted. It may not seem obvious that this should be so, but it actually looks for and preprocesses any filters at startup.
This has been a pretty quick introduction to servlet filters. You'll notice we didn't look at a single line of Java code. We're not interested here in creating filters, just in using them. There are plenty of resources for learning more about creating them - though there's not too much more you need to know about using them. We've run out of room to cover any further details, but if you're interested in more on this subject, including a few other tips that may help you as you explore them, take a look at the slides from my one-hour user group presentation, "Augmenting Application.cfm with Filters," available at my site at www.systemanage.com/presentations.
- Where Are RIA Technologies Headed in 2008?
- The Next Programming Models, RIAs and Composite Applications
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Constructing an Application with Flash Forms from the Ground Up
- Building a Zip Code Proximity Search with ColdFusion
- Personal Branding Checklist
- CFEclipse: The Developer's IDE, Eclipse For ColdFusion
- Has the Technology Bounceback Begun?
- Adobe Flex 2: Advanced DataGrid
- i-Technology Viewpoint: We Need Not More Frameworks, But Better Programmers
- Web Services Using ColdFusion and Apache CXF
- Cloud People: A Who's Who of Cloud Computing