The request cycle processor is responsible for handling the steps of a request cycle. It's methods are called in a pre-defined order:

• resolve(RequestCycle, RequestParameters) is called to get the request target. A request might refer to e.g. a bookmarkable page, a listener interface call on a component on a previously rendered page, a shared resource or e.g. a non-wicket resource that resides in the web application folder.
• processEvents(RequestCycle) is called after the target is resolved. It is meant to handle/ distribute events like e.g. listener interface calls on components. During this processing, the request target may be changed (e.g. by calling setResponsePage). What actually happens is that RequestCycle holds a stack of targets, of which it will take to last addition as the recent one, but walks the whole stack in order to do cleaning up after the request is handled.
• respond(RequestCycle) is called to create a response to the requesting client. Typically, the actual response handling is to be (or delegated) by the request target implementation, but different strategies might do as they seem fit.
• respond(RuntimeException, RequestCycle) is called whenever an uncaught exception occurs during the event handling or response phase so that an appropriate exception response can be generated. This method is guaranteed to be called whenever such an exception happens, but will never be called otherwise.

A convience implementation that makes breaking up this processor in smaller delegate strategies easier can be found as CompoundRequestCycleProcessor (or AbstractCompoundRequestCycleProcessor ).