The org.zkoss.zk.ui.event.EventThreadResume interface
A listener could implement EventThreadResume, such that it will be called after an event processing thread is resumed or aborted.
Notice that it is useless unless the event processing threads are enabled (it is disabled by default).
If a listener implements this interface, an instance is created, and then the
beforeResume method is called in the main thread (aka., the servlet thread), when a suspended event thread is being resumed. Then, the
afterResume method is called in the event processing thread after the thread is resumed successfully.
If a developer wants to prevent an event from being resumed, he can throw an exception in the
beforeResume executes in the main thread, so it shares the same thread-local storage with the main thread. On the other hand,
afterResume executes in the event processing thread, so it shares the same thread-local storage with the event thread (and application event listeners).
In addition to resuming normally, a suspended event processing thread might be aborted abnormally. For example, when the desktop is destroyed, all the suspended event threads will be aborted. When the suspended event processing thread is aborted, an instance is created, and the
abortResume method is called in the main thread.
Note: If a suspended event thread is aborted, none of the
afterResume is called. Moreover, the
complete methods of
EventThreadCleanup won't be called, either. Thus, you have to handle all necessary cleanups in
Instantiation: An independent instance of the given class is instantiated each time before the method is invoked. It means it is thread safe, and all information stored in non-static members will be lost after called.