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.