Weld provides integration between the Apache Wicket web framework and CDI. This functionality is provided by the weld-wicket extension module, which naturally must be on the classpath of the Wicket application. This section describes some of the utilities provided by the Wicket extension module to support the CDI integration.

Each wicket application must have a WebApplication subclass; Weld provides, for your utility, a subclass of this which sets up the Wicket CDI integration. You should subclass org.jboss.weld.wicket.WeldApplication. If you would prefer not to subclass WeldApplication, you can manually add a (small!) number of overrides and listeners to your own WebApplication subclass. The JavaDocs of WeldApplicationdetail this. For example:

Wicket can also take advantage of the conversation scope from CDI, provided by the Wicket extension 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 in JSF applications, a conversation always exists for any request to Wicket, but its lifetime is only that of the current request unless it is marked as long-running. The boundaries of a long-running conversation are controlled in the same way as in JSF applications, by injecting the Conversation instance and invoking either the begin() or end() methods:

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.