SeamFramework.orgCommunity Documentation
Each wicket application must have a
WebApplication subclass; Web Beans provides, for
your utility, a subclass of this which sets up the Wicket/JSR-299
integration. You should subclass
org.jboss.webbeans.wicket.WebBeansApplication.
If you would prefer not to subclass
WebBeansApplication, you can manually add a
(small!) number of overrides and listeners to your own
WebApplication subclass. The javadocs of
WebBeansApplicationdetail this.
For example:
public class SampleApplication extends WebBeansApplication {
@Override
public Class getHomePage() {
return HomePage.class;
}
}
The conversation scope can be used in Web Beans with the Apache
Wicket web framework, through the webbeans-wicket
module. This module takes care of:
Setting up the conversation context at the beginning of a Wicket request, and tearing it down afterwards
Storing the id of any long-running conversation in Wicket's metadata when the page response is complete
Activating the correct long-running conversation based upon which page is being accessed
Propagating the conversation context for any long-running conversation to new pages
As JSF applications, a conversation
always exists for any request, but its
lifetime is only that of the current request unless it is
marked as long-running. For Wicket
applications this is accomplished as in JSF applications, by
injecting the @Current Conversation and
then invoking conversation.begin().
Likewise, conversations are ended with
conversation.end()
When a conversation is marked as long-running, the id of that
conversation will be stored in Wicket's metadata for the current
page. If a new page is created and set as the response target
through setResponsePage, this new page will
also participate in this conversation. This occurs for both
directly instantiated pages
(setResponsePage(new OtherPage())), as well as
for bookmarkable pages created with
setResponsePage(OtherPage.class) where
OtherPage.class is mounted as bookmarkable
from your WebApplication subclass (or through
annotations). In the latter case, because the new page instance
is not created until after a redirect, the conversation id will
be propagated through a request parameter, and then stored in
page metadata after the redirect.