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

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

Before. On Sat, May 30, 2009 at 2:11 PM, Clint Popetz <cpopetz(a)gmail.com&gt; wrote: > Before or after servlet filters have run? > > -Clint > > On Sat, May 30, 2009 at 4:08 PM, Gavin King <gavin.king(a)gmail.com&gt; 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(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 > >> >> > 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 > > > > -- > 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

On Sat, May 30, 2009 at 2:26 PM, Clint Popetz <cpopetz(a)gmail.com&gt; 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

the page map.

On Sat, May 30, 2009 at 5:26 PM, Clint Popetz <cpopetz(a)gmail.com&gt; 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. 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. > The problem you describe with Wicket is exactly what I want to avoid with JSF. In JSF, it's a chicken egg problem to try to restore the view to determine what type of conversation you have active. So I definitely support having the conversation start as early as possible, before application code starts firing. I think it is mistake to bury conversation token information in a page object. It needs to be there before the framework gets going. So I support doing this before filters fire.

You can always decide to end the conversation or recreate it once you determine that, for whatever reason, you don't want that conversation (I'm not able to come up with a scenario right now). Another approach is to have the framework (JSF, Wicket, etc) raise the event to instruct the manager how to construct the conversation. In the case of Wicket, you could do that somewhere mid-way in the filter.