Table of Contents 
Previous Section
Starting the Request-Response Loop
A WebObjects application's entry point is the same as that of any C program: the main function. In a WebObjects application, main is usually very short. Its job is to create and run the application.The main function typically consists of a single line of code that calls the WOApplicationMain function, passing the name of your application's principal class and any arguments you may have passed to your application. WOApplicationMain processes any arguments, then creates an instance of your principal class (which should be a subclass of WOApplication, and is named Application by default). In your application class' init method (or constructor) the application creates and stores one or more adaptors in an instance variable. These adaptors-all instances of a WOAdaptor subclass-handle communication between an HTTP server and the WOApplication object. The application first parses user defaults dictionary for the specified adaptors (with necessary arguments); if none are specified, it creates a suitable default adaptor.
Also during application initialization, the application object creates its pool of WORequestHandlers. By default, applications have three request handlers: one for component actions (WOComponentRequestHandler), one for direct actions (WODirectActionRequestHandler), and one for resource requests (WOResourceRequestHandler). All three of these are private subclasses of WORequestHandler. If your application has additional request handlers, they should be registered with the application at application initialization time.
After your application class has been initialized, WOApplicationMain sends it a run message, initiating the request-response loop. When run is invoked, the application sends registerForEvents to each of its adaptors to tell them to begin receiving events. Then the application begins running in its run loop.
The autorelease pool is released and recreated immediately before the run message is sent. Releasing the autorelease pool at this point releases any temporary variables created during initialization of the application class. Creating a new autorelease pool before sending run ensures that all variables created while running the application will be released eventually. The last message releases the autorelease pool, which in turn releases any object that has been added to the pool since the application started running.
In the rest of this section, we look at what happens during one complete cycle of the request-response loop.
Table of Contents 
Next Section