Context Docs: HTTP Context in Depth
An HTTPContext is nothing more than a PluggableContext with an additional method; respond(). In fact, the HTTPContext IS A PluggableContext and as such, extends it. The purpose of an HTTPContext is to leverage it's classes and plugins to produce a web application - something that on it's own can understand an HTTP request and produce an meaningful HTTP response. While a PluggableContext is meerly a collection of CFC Class instances and Plugin behaviors, an HTTPContext leverages any registered HTTPPlugins to produce it's web behaviors.
respond()
Seeing as how this method is the only thing that distinguishes the HTTPContext from it's parent PluggableContext we're going to delve into its behavior right now. It's really quite simple, when this method is invoked on the context, the context simply invokes the getResponse() method on each and every registered HTTPPlugin in the order in which they were registered with the context. Each registered HTTPPlugin will have an opportunity to introspect the response provided by the previous HTTPPlugin and change it if needed - or simply leave it alone. The response returned from the last HTTPPlugin in the chain of responsibility is what ultimately gets returned to the requesting client.
Order Matters
This is precisely why the order of registered HTTPPlugin instances matter. For instance, when using the SimpleSecurityPlugin to secure HTTP requests, you want that plugin registered first so that it can intercept HTTP requests before they are processed by other context HTTPPlugin instances. Similarly, you would want the FaceplaitPlugin registered last so it could properly handle rendering layouts for HTML responses. When working with simple Plugin (non HTTP) instances - which most certainly can be used within an HTTPContext, order does not matter.
Application.cfc
When working with an HTTPContext, propery initialization and caching is important. In a production environment, you wouldn't want the context recreated and initialized on every request as this is only necessary once during application startup, conversely that may be the exact behavior you would want in a development environment. This is why a default implementation of Application.cfc is provided for you in the org.cfcommons.context.impl package. This Application.cfc component provides all of the pre-coded plumbing required to effectively initialize your context AND service requests. Of course, you are not required to use this but you would of course be responsible for providing the correct caching and initialization procedures on your own. All you need to do is simply extend this CFC with your own Application.cfc and provide the following configuration options;
The value of the this.cfcommons.context.config.file must reference the location of your context configuration file. It can be either a relative path from your web root, in which case the context will attempt to determine the actual system file path OR you can provide the actual system file path on your own. In the above example, we're providing the actual system file path determined dynamically by using the expandPath() method. This configuration option is entirely optional, if you choose to omit it, then the application will look for a context-config.xml file within the same directory as the Application.cfc file itself.
The value of the this.cfcommons.context.config.env must contain a value that directly corresponds with a configured environment within your context, otherwise an exception will be thrown.
Of course, your Application.cfc is a regular old CFC so you can make it more inteligent about where the location of the configuration file is depending upon your environment OR dynamically determine which environment to use like so;
In the above example, as long as the current request is coming from the localhost (by name or IP), the development environment will be used.