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

--

Gavin King
gavin.king@gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org