[webbeans-dev] conversation context lifecycle

[Gavin King]

How much control do we have over filter ordering in the new servlet
spec? now that web.xml fragments can be packaged into modules? Is it
possible to define a total ordering?

On Sun, May 31, 2009 at 1:49 PM, Michael Youngstrom <youngm at gmail.com> wrote:
> The after filter solution still isn't going to make everyone happy
> either.  For example, if someone wants to provide some solution that
> hides the conversation in the JSF view state then this would not work
> for them either.
>
> If you want to keep it simple then just define the Conversation as
> being available for the whole request using a request parameter for
> propagation.  We could still add to this default conversation
> implementation the Extension event.  And this would be the definition
> of the default provided @ConversationScoped Context.  If JSF or Wicket
> wishes to manage the conversation id in a completely different way
> then let them provide their own Context implementation for
> @ConversationScoped. :)
>
> So rather than catering to Wicket or JSF let's just cater to the
> servlet spec and let frameworks create their own ConversationContext
> if they want more control over Conversation propagation.
>
> Mike
>
>
> On Sun, May 31, 2009 at 1:40 PM, Gavin King <gavin.king at gmail.com> wrote:
>> 2009/5/30 Michael Youngstrom <youngm at gmail.com>:
>>> I'm not really happy with this solution.  Over the last couple of
>>> hours I've really grown to like the power of a more servlet general
>>> conversation available to the full request.  If a developer doesn't
>>> care about using a request parameter they shouldn't have to live with
>>> the post Filter restriction.
>>
>> I'm also finding this idea to be pretty seductive.
>>
>>> Isn't there some way we can make the conversation context more
>>> pluggable/extensible itself?  WebBeans could ship with a general
>>> friendly request parameter based conversation propagation mechanism
>>> and other frameworks like Wicket could replace or extend the provided
>>> Conversation Manager to better fit their propagation requirements
>>> along with the potential limitations?
>>
>> In this release I don't want to do something extremely complex here.
>> If there is a simple solution that covers the major integration
>> usecases that we can think of, fine, let's go with it. But if not, I
>> would rather defer it.
>>
>>
>> --
>> 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