Advanced Macromedia ColdFusion MX 7 Application Development
| ColdFusion is a J2EE application. The ColdFusion Enterprise Edition is deployable on multiple J2EE application server instances. Supported J2EE application servers include Macromedia JRun, BEA WebLogic, IBM WebSphere, and Sun Application Server. Running ColdFusion in multiple instances on J2EE application servers provides scaling through application isolation and server clustering/failover. You can combine multiple server instances with multi-homed Web servers to provide complete application and Web site isolation. NOTE For information on configuring application isolation with multi-homed Web servers, see "Web Server configuration for Application Isolation" in the Configuring and Administering ColdFusion manual at http://livedocs.macromedia.com/coldfusion/7/htmldocs/00001773.htm. ColdFusion MX 7 Enterprise Edition in Multiserver configuration introduces the ability to configure JRun server instances and automatically deploy an instance of the ColdFusion MX 7 application server to those instances from within the ColdFusion Administrator. Administrators can combine this feature with the J2EE Archives feature to deploy packaged ColdFusion applications that contain the application server, application files (.cfm, .cfc, .cfr, etc.), and server settings (data source definitions). NOTE Chapter 6, "Deploying Applications," provides more details on packaging ColdFusion application servers as J2EE Archives. Chapter 4, "Scaling with J2EE," discusses configuring multiple instances with the ColdFusion Instance Manager. Running multiple instances of ColdFusion on J2EE application servers provides the following security benefits:
Configuration Issues for Multi-homed Web Servers
Most ISPs operate in a multi-homed environmenta server containing multiple virtual Web server instances, each with a separate Web root. This is also known as multi-hosting; a server hosts multiple domain names on a single IP address. In these configurations, each virtual server has a different Web root and domain name, but a single ColdFusion server answers requests for all virtual servers. When configuring ColdFusion in these environments beware of the following issues, which are discussed in the sections that follow:
NOTE Most of the information in this section describes issues with multi-homed configurations affecting ColdFusion MX 6.0. These issues were corrected in the 6.1 release. The information in this section may prove useful for administrators upgrading from ColdFusion MX 6.0 to 7, or who have a misconfigured 6.1 installation.
Problems with the Stand-Alone Web Server and Web Server Path Caching
The ColdFusion MX 6.0 stand-alone Web server ran by default after an install. ColdFusion MX 6.1 fixed this issue; however, it is still considered a best practice to install ColdFusion using the stand-alone Web server, and then enable external Web server support after completing the Configuration Wizard. The stand-alone Web server runs on port 8500 by default. Keep in mind that running the stand-alone server in addition to your production Web server adds overhead and potential security risks on port 8500. TIP If it detects an existing ColdFusion server bound to port 8500, the ColdFusion MX 7 stand-alone Web server may bind to port 8501. This allows both versions to run simultaneously. If port 8501 is taken, the stand-alone server will continue to search incrementally until it finds an open port.
ColdFusion MX 6.0 also enabled template path caching by default to optimize performance. On multi-homed servers, template path caching may cause the incorrect display of all templates with relative paths similar to their respective Web server roots. For example, ColdFusion will cache the first request for http://www.mysite.com/products/index.cfm, and any subsequent calls to http://www.yoursite.com/products/index.cfm will display the cached /products/index.cfm page results for www.mysite.com because the relative paths are similar. This problem was corrected in ColdFusion Updater 2, but administrators should still be wary of this issue. TIP See the Macromedia ColdFusion Release Notes (http://www.macromedia.com/support/documentation/en/coldfusion/releasenotes.html) for more information on these and other issues.
You can shut down the stand-alone Web server and disable Web server path caching either in the cf_root\runtime\servers\coldfusion\SERVER-INF\jrun.xml (Server configuration) or in jrun_root\servers\coldfusion\SERVER-INF\jrun.xml (Multiserver configuration). Use the following steps to modify the jrun.xml file:
Issues with ColdFusion Administrator Access
The ColdFusion Administrator should only be accessed from one Web server instance. This keeps administration simple and helps augment the ColdFusion Administrator security. Because all ColdFusion Administrator instances modify the same configuration files, having multiple instances can cause unforeseen problems leading to server instability or failure. However, should access to the ColdFusion Administrator be required from virtual sites, create a virtual mapping to the originally installed CFIDE directory. You can also create local CFIDE directories for individual virtual servers and copy to them the code from the original CFIDE; this does, however, add an additional administration step of keeping the code in sync. NOTE Access to ColdFusion Administrator functionality is now available via the ColdFusion Administrator API in CFMX 7. See Chapter 11, "Using the Administration API," for details. TIP You can use the Web Server Configuration Tool's -cfwebroot option, to allow access to the CFIDE directory under the specified Web root when configuring virtual server integration with ColdFusion.
Access to the cfform.js File
The cfform.js contains the client-side JavaScript used for <cfform> validation. The default location for this file is CFIDE/scripts. If this folder is not available to all virtual servers, the <cfform> validation will fail. If application logic in any of the virtual servers will use <cfform>, take one of the following actions:
|