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.  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.

So I think this mechanism won't keep frameworks like wicket from operating conversationally.

-Clint

On Sat, May 30, 2009 at 4:19 PM, Gavin King <gavin.king@gmail.com> wrote:
Before.

On Sat, May 30, 2009 at 2:11 PM, Clint Popetz <cpopetz@gmail.com> wrote:
> Before or after servlet filters have run?
>
> -Clint
>
> On Sat, May 30, 2009 at 4:08 PM, Gavin King <gavin.king@gmail.com> wrote:
>>
>> The point is that the container would be required to fire it on *all*
>> servlet requests.
>>
>> On Sat, May 30, 2009 at 2:08 PM, Clint Popetz <cpopetz@gmail.com> wrote:
>> > I presume this event is only being fired from the WebBeansPhaseListener
>> > and
>> > won't exist for non-faces requests?
>> >
>> > -Clint
>> >
>> > On Sat, May 30, 2009 at 3:41 PM, Gavin King <gavin.king@gmail.com>
>> > wrote:
>> >>
>> >> Or we could say it is an event that is observable by Extensions:
>> >>
>> >>   void request(@Observes BeforeRestoreConversation brc) {
>> >>       brc.setId( brc.getRequest().getParameter("specialcid") );
>> >>   }
>> >>
>> >> where we define the following interface:
>> >>
>> >>   public interface BeforeRestoreConversation {
>> >>      String getId();
>> >>      void setId(String id);
>> >>      ServletContext getContext();
>> >>      HttpServletRequest getRequest();
>> >>   }
>> >>
>> >> This seems to me like the better option, WDYT?
>> >>
>> >> On Sat, May 30, 2009 at 1:31 PM, Gavin King <gavin.king@gmail.com>
>> >> wrote:
>> >> > On Sat, May 30, 2009 at 12:43 PM, Gavin King <gavin.king@gmail.com>
>> >> > wrote:
>> >> >
>> >> >>> Looking at the Conversation public API I don't see any programmatic
>> >> >>> way to restore a conversation.  Perhaps we should add such an API?
>> >> >>
>> >> >> Ugh, I really didn't want to go there in this release, though it
>> >> >> would, very clearly, be a very useful feature.
>> >> >>
>> >> >> If we were going to go there, the way I would do it is to say that
>> >> >> the
>> >> >> conversation context is defined for all servlet requests, but it is
>> >> >> by
>> >> >> default transient. The container would be required to call back to
>> >> >> Extensions to obtain a conversation id.
>> >> >
>> >> > Actually, upon reflection, I think we need to do this :-/
>> >> >
>> >> > Because even in JSF, we want a way to customize the mechanism for
>> >> > conversation propagation.
>> >> >
>> >> > So we could say that an Extension may optionally implement this
>> >> > interface:
>> >> >
>> >> >    public interface ConversationExtension {
>> >> >        String getConversationId(HttpServletRequest request,
>> >> > ServletContext context);
>> >> >    }
>> >> >
>> >> > And say that before any Filter is called, the container calls all
>> >> > ConversationExtensions looking for a conversation id, and if it finds
>> >> > one, restores the conversation.
>> >> >
>> >> > Alternatively, we could say that the conversation is only restored
>> >> > *after* all ServletFilters have been called, and say that the
>> >> > container looks in a specially-named request attribute, for example
>> >> > "javax.contexts.spi.conversationId". Then we would not need a special
>> >> > interface, and any servlet filter could do conversation management.
>> >> > This seems more elegant, but means you don't get a conversation
>> >> > context in your filters.
>> >> >
>> >> > WDYT?
>> >> >
>> >> > --
>> >> > Gavin King
>> >> > gavin.king@gmail.com
>> >> > http://in.relation.to/Bloggers/Gavin
>> >> > http://hibernate.org
>> >> > http://seamframework.org
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Gavin King
>> >> gavin.king@gmail.com
>> >> http://in.relation.to/Bloggers/Gavin
>> >> http://hibernate.org
>> >> http://seamframework.org
>> >>
>> >> _______________________________________________
>> >> webbeans-dev mailing list
>> >> webbeans-dev@lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>> >
>> >
>> >
>> > --
>> > Clint Popetz
>> > http://42lines.net
>> > Scalable Web Application Development
>> >
>>
>>
>>
>> --
>> Gavin King
>> gavin.king@gmail.com
>> http://in.relation.to/Bloggers/Gavin
>> http://hibernate.org
>> http://seamframework.org
>
>
>
> --
> Clint Popetz
> http://42lines.net
> Scalable Web Application Development
>



--
Gavin King
gavin.king@gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org



--
Clint Popetz
http://42lines.net
Scalable Web Application Development