[webbeans-dev] conversation context lifecycle

[Clint Popetz]

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