On Sat, May 30, 2009 at 7:38 PM, Gavin King
<gavin.king@gmail.com> wrote:
On Sat, May 30, 2009 at 2:26 PM, Clint Popetz <
cpopetz@gmail.com> wrote:
> The wicket webbeans conversation mechanism stores the conversation id in a
> page map that is only accessible once the wicket filter has run and
> determined which page is being used. So this mechanism wouldn't work for
> Wicket.
before restoring the Conversation. bummer.
The problem is that Wicket runs _from_ the filter, not from a servlet; if you wait until the filter has run, it will be too late.
> However since there is no default cid=NNN parameter being generated
> by anyone for wicket, and the conversation mechanism in the container just
> defaults to a transient conversation without one, the wicket conversation
> hooks that runs from the WicketFilter can (I presume) still obtain the
> @Current Conversation and call begin(id) once it has found the correct id in
> the page map.
No, begin() isn't meant to let you resume an existing conversation.
Oof. Currently the wicket/webbeans integration uses ConversationManager.beginOrRestoreConversation, which is webbeans-specific. Is there no way to provide something like that in the SPI?
So, then, is the best solution to let a Filter set the request
attribute "javax.context.spi.conversationId"?
Wicket doesn't know the conversation id until it does request-specific handling, and that happens in the WicketFilter, but it needs to be able to programatically trigger an immediate restore of the conversation so that the subsequent handling of the request in the filter has a conversation context. So we can't do this via setting a request attribute.
-Clint