Java Platform, Enterprise Edition

Java EE Journal

Subscribe to Java EE Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Java EE Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


J2EE Journal Authors: APM Blog, Stackify Blog, Sumith Kumar Puri, Javier Paniza, Yakov Fain

Related Topics: ColdFusion on Ulitzer, Java EE Journal

CFDJ: Article

Undocumented ColdFusion MX - 2

Undocumented ColdFusion MX - 2

Several months ago I wrote a column entitled "Undocumented ColdFusion MX - 1," (CFDJ, Vol. 4, issue 9). I appended a "1" to the title in anticipation of there being a "2" at some later date. Well, that time has come. That column (which apparently was highly controversial and upset quite a few readers, but fortunately made even more happy) exposed and explained the use of the ColdFusion factory object. This time we'll look at some of the configuration files used by ColdFusion MX - files that can be tweaked as needed (and no controversy this time, I think).

Caveat emptor: Undocumented means unsupported - you may access and tweak the files discussed here, but you do so at your own risk. Undocumented features and files may be changed or removed in future versions of products. That's what distinguishes the documented from the undocumented - vendors are under no obligation to support anything undocumented. Use at your own risk.

Introduction
Unlike previous versions of ColdFusion that stored all sorts of configuration options and settings in the Windows registry (or a registry emulator on Unix machines), most ColdFusion MX configuration options are stored in XML files. There are lots of benefits to storing configuration information in XML files, but for ColdFusion developers, two benefits stand out:

  • Tweaking the registry was painful (and rather scary); XML files are easily (maybe too easily) read and accessed (by both man and machine).
  • Unlike the registry, XML files are suitable for use on all operating systems.

    But before you even touch ColdFusion's configuration files, here are a few rules to keep in mind:

  • Always make backups.
  • Some of the ColdFusion

    XML files are well documented (in embedded comments), others are not. If you can't find the documentation you need, well, you probably won't. With one exception, the files that configure the integrated JRun server (and HTTP server) are documented in the JRun documentation (but not the ColdFusion documentation).

  • If you do make changes you'll usually need to restart ColdFusion for those changes to take effect.
  • Use a real editor; XML is picky, if you drop an ending tag or mess up nesting or lose a quote, well, things will break. So, be safe, and use an editor that is XML aware.

    One final note - the files and directories referred to here apply to ColdFusion MX. If you are using ColdFusion MX for J2EE, then paths and files will likely differ.

    XML Files, Mostly
    Ready to look at XML files? Great, but first, one non-XML file that you should be aware of. The lib directory under the ColdFusion root contains a file named password.properties. This file contains the ColdFusion Administrator and RDS passwords. You can't change the passwords in this file directly, but if you do forget your ColdFusion Administrator password, you can use this file to gain entrance. Here's how:

    1.   Open the password.properties file in a text editor.
    2.   Delete the password and rdspassword values (all text after the =).
    3.   Change the value of encrypted to false.
    4.   Save the file.
    5.   Restart ColdFusion. You'll now be able to access the ColdFusion Administrator to set a new password.

    There are other .properties files in the lib directory, but you'll find them to be of little interest.

    The web.xml File
    The web.xml file is an important one. It is found in the WEB-INF directory under the Web root. The top of the file contains several application parameters in <context-param> sections. One of the parameters is named coldfusion.compiler.saveJava and, as its name suggests, if set to true, will force the ColdFusion compiler to save the generated Java source code (instead of just the compiled bytecode). You'll not want to ever edit the .java files directly, but if you are curious as to what the ColdFusion-generated Java code looks like (or if you need help proving to some naysayer that ColdFusion really is a Java compiler) then set this parameter to true.

    This file also contains a series of servlet mappings, each in a section named <servlet-mapping>. These specify the file extensions that ColdFusion should process. You'll not want to change any of the default mappings, but if you want ColdFusion to process additional file extensions then you'll want to add those mappings here. The safest way to do this is to copy an entire section (from <servlet-mapping> to </servlet-mapping>) and then just edit the <url-pattern> as needed.

    You can also use web.xml to completely disable ColdFusion RDS if needed (many administrators opt to do this on production servers as a security precaution). Prior to ColdFusion MX, RDS could be disabled by simply not running the RDS service; in ColdFusion MX it's a little trickier. To disable RDS, locate the <servlet-mapping> for the servlet named RDSServlet, and comment out the entire section using <!-- and --> (from before <servlet-mapping> until after the matching </servlet-mapping>).

    web.xml also contains a list of default files (or welcome files). These are the files that will be used if a URL contains a directory name but not an explicit file name. The default file names are index.cfm, index.html, and index.htm, and are listed in a section entitled <welcome-file-list> (each file is specified as a <welcome-file>). You may add file names to this list if needed. Just remember that files are located and used in the order defined.

    Another interesting configuration option in this file is the <error-page> section, which is used to map specific HTTP errors to CFM files that are used when the error occurs. By default, only HTTP error code 500 is mapped, but you can add your own mappings if you so wish.

    The jrun-web.xml File
    The jrun-web.xml file is in the same directory as web.xml. You'll only want to edit this file if you change the location of the ColdFusion document root after installation. jrun-web.xml contains a series of <virtual-mapping> sections, and to change the document root, edit the /* mapping as needed.

    If you do move the document root, be sure to move the CFIDE directory to the new document root or you'll not have access to the ColdFusion Administrator, the CFC viewer, <CFFORM> .js files, and more.

    The jrun.xml File
    Another extremely important file is the jrun.xml file, which is under the ColdFusion root in the \runtime\servers\default\SERVER-INF directory. As its name suggests, jrun.xml is used to configure ColdFusion's integrated JRun server. Be extremely careful in this file, you'll not want to make changes without really knowing what you're doing.

    But there is one section that you should be aware of. The file contains <service> sections used to configure the various services used by JRun (even if you are not using JRun directly). One of those services is the integrated HTTP server that's configured in the section named jrun.servlet.http.WebService. If you want to change the port that the integrated HTTP server runs on (the default is 8500) or want to disable it altogether (deactivate it), this is where you can do that.

    Another extremely important setting in jrun.xml is the cacheRealPath parameter for the proxy service. If you have multiple Web sites on a single host, you must turn this option off (or you will end up with the wrong files being served when file names conflict). Unfortunately, by default, cacheRealPath is true, so if you do have multiple Web sites (as most of us do), edit this file, locate the <service> named ProxyService, find the attribute named cacheRealPath, and set it to false.

    The default-web.xml File
    default-web.xml is in the same SERVER-INF directory as jrun.xml. This file defines servlets used by JRun, one of which is the FileServlet. This servlet has a configuration parameter named browseDirs that controls file browsing (the behavior whereby if a URL is requested without an explicit file name specified, then a directory of files can be displayed for selection). The default is true (display file list for browsing and selection); set it to false to prevent file browsing.

    What Next
    As you can see, ColdFusion's configuration files are extremely important, and whether you need to tweak them or not, you should be aware of what they are and what they do. Of course, most of what they do is not for us mere mortals to know, but here's a hint - scan the Macromedia Support TechNotes for articles on JRun's configuration files. Much of what you'll find there applies to ColdFusion MX as well.

    Summary
    ColdFusion MX made the move from proprietary to standards based, and with that move came XML configuration files that control just about every aspect of ColdFusion (and its underlying JRun server). As long as you proceed with caution, being able to tweak these files can be a lifesaver.

  • More Stories By Ben Forta

    Ben Forta is Adobe's Senior Technical Evangelist. In that capacity he spends a considerable amount of time talking and writing about Adobe products (with an emphasis on ColdFusion and Flex), and providing feedback to help shape the future direction of the products. By the way, if you are not yet a ColdFusion user, you should be. It is an incredible product, and is truly deserving of all the praise it has been receiving. In a prior life he was a ColdFusion customer (he wrote one of the first large high visibility web sites using the product) and was so impressed he ended up working for the company that created it (Allaire). Ben is also the author of books on ColdFusion, SQL, Windows 2000, JSP, WAP, Regular Expressions, and more. Before joining Adobe (well, Allaire actually, and then Macromedia and Allaire merged, and then Adobe bought Macromedia) he helped found a company called Car.com which provides automotive services (buy a car, sell a car, etc) over the Web. Car.com (including Stoneage) is one of the largest automotive web sites out there, was written entirely in ColdFusion, and is now owned by Auto-By-Tel.

    Comments (3) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Fabrice Billiotel 02/10/06 03:07:38 PM EST

    Hi Ben,

    Well i've modified web.xml file to ask ColdFusion to process pdf file extensions.
    It works fine but i have a problem :
    if pdf file contains something like

    Leif 05/07/03 09:20:00 PM EDT

    Jeff,

    In order to access the file, you'd need admin rights on the server it runs on - and if you had that, you could do lots more than just change CF Admin settings. Keep the server secure and you're OK.

    Jeff 04/10/03 09:41:00 PM EDT

    Ben-
    Doesn't the info you gave on page 2, about password.properties, allow anyone to change the admin password and thus circumvent the reason there is a password in the first place?

    If I read this correctly, you just gave hackers a backdoor into the CF admin controls, which is pretty scary.

    Please tell me I misread this and that I just don't understand some part of it.

    Jeff