[webbeans-dev] conversation context lifecycle

[Clint Popetz]

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 at gmail.com> wrote:

> Before.
>
> On Sat, May 30, 2009 at 2:11 PM, Clint Popetz <cpopetz at gmail.com> wrote:
> > Before or after servlet filters have run?
> >
> > -Clint
> >
> > On Sat, May 30, 2009 at 4:08 PM, Gavin King <gavin.king at 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 at 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 at 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 at gmail.com>
> >> >> wrote:
> >> >> > On Sat, May 30, 2009 at 12:43 PM, Gavin King <gavin.king at 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 at gmail.com
> >> >> > http://in.relation.to/Bloggers/Gavin
> >> >> > http://hibernate.org
> >> >> > http://seamframework.org
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Gavin King
> >> >> gavin.king at gmail.com
> >> >> http://in.relation.to/Bloggers/Gavin
> >> >> http://hibernate.org
> >> >> http://seamframework.org
> >> >>
> >> >> _______________________________________________
> >> >> webbeans-dev mailing list
> >> >> webbeans-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/webbeans-dev
> >> >
> >> >
> >> >
> >> > --
> >> > Clint Popetz
> >> > http://42lines.net
> >> > Scalable Web Application Development
> >> >
> >>
> >>
> >>
> >> --
> >> Gavin King
> >> gavin.king at 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 at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>



-- 
Clint Popetz
http://42lines.net
Scalable Web Application Development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090530/c72ec273/attachment.html