Using ColdFusion Server Variables

Most of you probably know that you can get a lot of information about your server environment from the implicit “server” variable scope, however what is not so obvious is why this information is useful. First of all, here is everything you can find out, and their values on my weblog server:

server.coldfusion.appserver #server.coldfusion.appserver#
server.coldfusion.expiration #server.coldfusion.expiration#
server.coldfusion.productlevel #server.coldfusion.productlevel#
server.coldfusion.productname #server.coldfusion.productname#
server.coldfusion.productversion #server.coldfusion.productversion#
server.coldfusion.rootdir (not available)
server.coldfusion.serialnumber (not available)
server.coldfusion.supportedlocales #server.coldfusion.supportedlocales#
server.os.additionalinformation #server.os.additionalinformation#
server.os.arch #server.os.arch#
server.os.buildnumber #server.os.buildnumber#
server.os.version #server.os.version#

Server variables are most often useful when your code needs to run in multiple environments, and you are not able to develop in a completely platform independent manner. For instance, you might need to to know what the server’s path separator is so that you can reference files on the file system. One way to get this information is from the variable, like this:

<cfset pathSep = iif( eq "UNIX",de("/"),de("\"))/>

You can also use the server.os.additionalinformation and server.os.version variables to determine if certain ColdFusion functionality (like Verity searches) are supported, or the server.coldfusion.productversion variable to make sure the user has installed your application with the right version of ColdFusion. If you are writing an application that you intend to distribute, and that can potentially be run on any platform that supports ColdFusion, a little platform validation can go a long way toward making installations more user friendly.

What other uses do people have for server variables?

5 Responses to Using ColdFusion Server Variables

  1. Another way to get the path separator, althought it seems to take longer:<cfscript>system = CreateObject(“java”, “java.lang.System”);pathSep = system.getProperty(“file.separator”).charAt(0);</cfscript>AJ

  2. Geoff Bowers says:

    Why not just always use “/”? Windows JVM is happy with either, it’s only *nix that has a problem.

  3. Don’t forget that if your only desire is to check for a particular version, you can also use getFunctionList(). I.e., if the result of structKeyList on getFunctionList() does not container X, where X is a CFMX function, then you know are running CF5. (Of course, this trick only works on CF version 5 and higher.)

  4. Mark Brinkworth says:

    The problem with always using “/”, is that it doesn’t work if you want to split up path names that have been retrieved through one of the various functions (e.g. getTemplatePath()) etc.

  5. I have agree with Mark, use the getTemplatePath() function instead. One an old project, I once had to go back change all occurances where I was directly accessing with slash to use the function. It was due to something that was changed in the server’s environment. If only we had used getTemplatePath, the application wouldn’t have been affected.