Re: [webbeans-dev] conversation context lifecycle

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; wrote: >> > On Sat, May 30, 2009 at 12:43 PM, Gavin King <gavin.king(a)gmail.com&gt; >> > 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(a)gmail.com >> > http://in.relation.to/Bloggers/Gavin >> > http://hibernate.org >> > http://seamframework.org >> > >> >> >> >> -- >> Gavin King >> gavin.king(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> >> _______________________________________________ >> webbeans-dev mailing list >> webbeans-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev > > > > -- > Clint Popetz > http://42lines.net > Scalable Web Application Development > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org