You could have some custom initialization and cleanup when an application, a session, a desktop or an execution is instantiated or about to be destroyed.

There are two steps:

  1. Implements the corresponding interface. For example, org.zkoss.zk.ui.util.WebAppInit

    for application’s initialization

  2. Register it in WEB-INF/zk.xml, or in Java.

Interfaces

Task Interface
Application Init org.zkoss.zk.ui.util.WebAppInit
Application Cleanup org.zkoss.zk.ui.util.WebAppCleanup
Session Init org.zkoss.zk.ui.util.SessionInit
Session Cleanup org.zkoss.zk.ui.util.SessionCleanup
Desktop Init org.zkoss.zk.ui.util.DesktopInit
Desktop Cleanup org.zkoss.zk.ui.util.DesktopCleanup
Execution Init org.zkoss.zk.ui.util.ExecutionInit
Execution Cleanup org.zkoss.zk.ui.util.ExecutionCleanup

Notice that ZK will instantiate an object from the class you registered for each callback. For example, an object is instantiated to invoke

org.zkoss.zk.ui.util.DesktopInit

, and another object instantiated to invoke

org.zkoss.zk.ui.util.DesktopCleanup

, even if you register a class that implements both

org.zkoss.zk.ui.util.DesktopInit

and

org.zkoss.zk.ui.util.DesktopCleanup

.

If you have something that is initialized in the init callback and have to clean it up in the cleanup callback, you cannot store it as a data member. Rather, you have to maintain it by yourself, such as storing it in the desktop’s attributes (org.zkoss.zk.ui.Desktop), session’s attributes or application’s attributes.

Registration

The registration in WEB-INF/zk.xml is the same, no matter what interface you implement:

<listener>
    <listener-class>my.MyImplementation</listener-class>
</listener>

The registration in Java is done by

org.zkoss.zk.ui.util.Configuration

.

webapp.getConfiguration().addListener(my.MyImplementation.class);