[webbeans-dev] conversation context lifecycle

[Clint Popetz]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090530/b88f21ca/attachment.html