The previous two lessons covered Application.cfc and its lifecycle in depth. This page is different on purpose: it's a companion interview-prep page, built around the specific questions people actually get asked, each paired with a plain-English real-world analogy so the differences actually stick.
The analogy used throughout: think of an application as a restaurant. Application.cfc is the restaurant's operations manual — it configures how the place runs, and defines what staff do in response to specific events (a customer walking in, the kitchen closing, an emergency).
"What is Application.cfc?"
What is Application.cfc, in plain English?
It's a special CFC ColdFusion automatically looks for and runs for every application. It has two jobs: configuration (settings on the this scope — the application's name, session timeout, and so on) and event handling (specially-named methods ColdFusion calls automatically when something happens — the app starting, a request coming in, an error occurring). Restaurant analogy: it's both the operations manual (hours, menu, staffing rules) and the trained staff who react to events (a customer arriving, the kitchen catching fire) without anyone having to tell them what to do each time.
Where does ColdFusion look for Application.cfc?
In the same folder as the requested page, or any folder above it, up to the web root. ColdFusion uses the first one it finds walking up that folder chain.
Is Application.cfc required for a ColdFusion application to work?
No. Without one, ColdFusion pages still run — there's just no Application scope, no session tracking, and none of the lifecycle event hooks. Almost every real application has one regardless, since the Application scope and session management depend on it.
onRequestStart vs onRequest vs onRequestEnd
This is the single most commonly confused trio. Restaurant analogy: a customer's full visit — the host checking them in, the meal actually being served, and the receipt printed afterward.
| Method | Restaurant equivalent | Fires |
|---|---|---|
| onRequestStart | The host checks the reservation and seats the customer | First, at the very start of the request |
| onRequest | The kitchen actually prepares and serves the meal | Right after onRequestStart — must explicitly "serve the page" (include it) or nothing runs |
| onRequestEnd | The receipt is printed and handed over as the customer leaves | Last, after all the page's own code has finished |
<cfscript>
function onRequestStart(targetPage) {
// the host: check the reservation (authorization) before seating anyone
if (!isUserLoggedIn()) {
writeOutput("Please log in first.");
return false; // turn the customer away — request stops here
}
return true;
}
function onRequest(targetPage) {
// the kitchen: actually serve the requested page
include arguments.targetPage;
}
function onRequestEnd(targetPage) {
// the receipt: runs after the page's own code, cleanup/footer logic
application.totalRequests++;
}
</cfscript>If onRequestStart returns false, the customer is turned away before ever reaching the kitchen — onRequest and onRequestEnd never run at all for that request.
onSessionStart vs onSessionEnd
Restaurant analogy: opening a tab for a customer when they sit down, and closing it out when they finally leave (or if they wander off without saying anything, and the tab times out from inactivity).
| Method | Restaurant equivalent | Fires |
|---|---|---|
| onSessionStart | A new tab is opened when a customer sits down | The first request of a brand-new session |
| onSessionEnd | The tab is closed out, final total recorded | The session times out from inactivity (not a literal "logout" click) |
<cfscript>
function onSessionStart() {
session.cart = []; // open a fresh tab
lock(scope = "application", timeout = 5) {
application.activeSessions++;
}
}
function onSessionEnd(sessionScope, applicationScope) {
// no "session" or "application" scope here directly — only the arguments
lock(name = "appLock", timeout = 5) {
arguments.applicationScope.activeSessions--;
}
}
</cfscript><cffunction name="onSessionStart" returnType="void">
<cfset session.cart = []>
<cflock scope="Application" timeout="5" type="Exclusive">
<cfset application.activeSessions++>
</cflock>
</cffunction>
<cffunction name="onSessionEnd" returnType="void">
<cfargument name="SessionScope" required="true">
<cfargument name="ApplicationScope" required="true">
<cflock name="appLock" timeout="5" type="Exclusive">
<cfset Arguments.ApplicationScope.activeSessions-- >
</cflock>
</cffunction>onSessionEnd can't reference session or application directly — it only receives them as SessionScope/ApplicationScope arguments, since it's not tied to an active request.
onApplicationStart vs onApplicationEnd
Restaurant analogy: the very first day the restaurant ever opens (checking the ovens work, the fridge is stocked) versus the restaurant closing down for good (or the building shutting off power).
| Method | Restaurant equivalent | Fires |
|---|---|---|
| onApplicationStart | Opening day checks: is the kitchen ready? | The application's very first request, ever (or after a timeout restart) |
| onApplicationEnd | Restaurant closes for good, final records saved | The application times out from inactivity, or the server shuts down |
onAbort vs onRequestEnd
Restaurant analogy: normally a receipt prints automatically at the end of a meal (onRequestEnd). But if the customer suddenly has to leave mid-meal (an early exit, not the normal ending), a different, shorter process happens instead (onAbort) — the full closing routine never runs.
| Method | Fires when |
|---|---|
| onRequestEnd | The request finishes normally, all page code completed |
| onAbort | Instead of onRequestEnd, if the page used <cfabort>, <cflocation>, or <cfcontent> |
onCFCRequest vs onRequest
Restaurant analogy: onRequest is the regular dine-in experience — a full page, served the normal way. onCFCRequest is more like a drive-thru window: a direct, programmatic call to a specific CFC over HTTP (Ajax, a web service, Flash Remoting) that skips the normal "seat the customer, serve the page" flow entirely.
| Method | Fires when |
|---|---|
| onRequest | A normal .cfm page is requested through a browser |
| onCFCRequest | A CFC is called directly over HTTP/AMF — instead of onRequest, not in addition to it |
onServerStart vs onApplicationStart
Restaurant analogy: onServerStart is the entire building's power coming on, before any individual restaurant inside it has opened for the day. It's not specific to any one restaurant (application) — it lives in a completely separate file, Server.cfc, and has to be explicitly enabled.
| Method | Lives in | Scope |
|---|---|---|
| onServerStart | Server.cfc (separate file, disabled by default) | The whole ColdFusion server — no specific application |
| onApplicationStart | Application.cfc | One specific application |
Interview Questions
What is Application.cfc used for?
Configuring an application (name, session/client settings, timeouts) and reacting to lifecycle events (application start, request start, errors) through specially-named methods ColdFusion calls automatically.
What's the difference between onRequestStart and onRequest?
onRequestStart runs first and handles setup/authorization, returning a boolean to allow or block the request. onRequest, if implemented, must explicitly include the target page — it's fully responsible for actually serving it.
When does onRequestEnd NOT run?
When the request used <cfabort>, <cflocation>, or <cfcontent> — onAbort runs instead in those cases.
What's the difference between onSessionStart and onApplicationStart?
onSessionStart fires once per new session (every individual visitor's first request). onApplicationStart fires once for the entire application (only the very first request anyone makes, or after a restart) — it doesn't fire again for every new visitor.
Why can't onSessionEnd or onApplicationEnd display output to the user?
Neither is tied to an active request — there's no page context to output to. They can still log information, just not render anything visible.
What's the difference between onCFCRequest and onRequest?
onRequest handles normal .cfm page requests. onCFCRequest handles CFCs called directly over HTTP/AMF (Ajax, web services, Flash Remoting) — it fires instead of onRequest for those calls, not alongside it.
Is onServerStart part of Application.cfc?
No — despite often being listed alongside the other lifecycle methods, onServerStart lives in a separate Server.cfc file, is disabled by default, and applies to the whole ColdFusion server rather than one specific application.
What arguments does onSessionEnd receive, and why can't it just use session/application directly?
It receives SessionScope and ApplicationScope as arguments. It can't reference session or application directly because the method runs when there's no active request tied to that session anymore.
How would you log every request's response time using Application.cfc?
Record a timestamp in onRequestStart (e.g. request.startTime = getTickCount()), then calculate and log the difference in onRequestEnd, since both share the Request scope for that request.
Summary
This page paired every commonly-confused Application.cfc method with a real-world restaurant analogy and a direct interview-style answer — onRequestStart/onRequest/onRequestEnd, onSessionStart/onSessionEnd, onApplicationStart/onApplicationEnd, onAbort, onCFCRequest, and onServerStart.
What's Next?
The next lesson covers ColdFusion's larger scopes in depth — Session, Application, Request — and how they compare to the function-local scopes covered earlier in the course.