Re: [webbeans-dev] conversation context lifecycle
On Sat, May 30, 2009 at 7:38 PM, Gavin King <gavin.king(a)gmail.com> wrote:
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
On Sat, May 30, 2009 at 2:26 PM, Clint Popetz
<cpopetz(a)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.
Ah, ok, then it sounds like we should wait till after Filters run
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.
Attachments:
- attachment.html (text/html — 2.6 KB)