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.
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.
So, then, is the best solution to let a Filter set the request
attribute "javax.context.spi.conversationId"?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org