The Life-Cycle of a Wicket Application

Loading the Application

A Wicket application runs in any J2EE compliant application server by
defining a Java servlet in the application's web.xml file:

...

When WicketServlet is loaded, it will use this information to instantiate a single
instance of your application class.

Servicing a Request

The following three steps occur each time that WicketServlet handles a
request:

...

3. The RequestCycle's request() method is called to handle the request.

How RequestCycle Handles a Request

For each request, a RequestCycle object does the following 3 things:

...

Step 2 may involve some pretty sophisticated logic. When a request
URL is parsed, it may include information such as a Component listener
to invoke. This Component listener may create a whole new Page that
is used

How Page Handles a Request

Page.request(), called in step 2 above, performs the following 3
steps to handle a request:

...

Once step 2 begins (the render phase for the Page), the Page becomes
immutable and it is no longer valid to alter either the Page's
component hierarchy or the values of any of its models. Attempting to
change the Page during rendering will generally result in a runtime
exception.

Clustering

When a Page is replicated from one machine in a cluster to another,
the onSessionAttach() method will be called for every component on the
Page.

Model Changes

When models or model values are changed in Wicket by a call to
setModel() or setModelObject(), the change results in a call to
onModelChanging() before the change actually occurs and then
onModelChanged() after the change occurs.

Because Wicket cannot always know if a model has changed, you can help
it to do smart things (such as versioning your Page's model changes)
by calling modelChanging() before altering a Component's model object
and modelChanged() afterwards. For example, if your component has a
Model that wraps a List object, there is no way for Wicket to know if
you set the 3rd element to some new value. By calling modelChanging()
and modelChanged(), you can ensure that Wicket knows about your change.

Rendering

A Page renders itself by rendering its associated markup (the html
file that sits next to the Page). As MarkupContainer (the superclass
for Page) iterates through the markup stream for the associated
markup, it looks up components attached to the tags in the markup by
id. Since the MarkupContainer (in this case a Page) is already
constructed and initialized by onBeginRequest(), the child for each
tag should be available in the container. Once the Component is
retrieved, it's render() method is called.

...