[webbeans-dev] conversation context lifecycle

[Matt Drees]

On Fri, May 29, 2009 at 5:30 PM, Gavin King <gavin.king at gmail.com> wrote:

> OK, Dan, I'll have to respect your judgment on this because I'm not up
> to date on how this stuff works in JSF2.
>
> So I'm happy to make changes with respect to JSF conversation
> propagation rules if it doesn't disrupt/delay the RI team (Pete,
> WDYT?) and if there are no objections from the EG (anyone?).


No, no objection here.


>
>
> But it seems that you're asking for two changes here:
>
> (1) that the conversation is restored at the beginning of RESTORE_VIEW


Is there any reason we can't require the conversation to be restored before
the invocation of any servlet filter?


>
> (2) that you want some kind of conversation propagation to other servlets
>
> Change (1) seems a pretty straightforward change.
>
> So we get to (2).
>
> Currently we don't even have a built-in conversation context in
> servlets and we would need some kind of additional rules surrounding
> conversation propagation between servlets. I think what you are
> suggesting is that the conversation is propagated whenever there is a
> request parameter named "cid" containing the conversation id, and that
> it is the user's responsibility to pass it along through the view.
> That doesn't sound unreasonable to me at this moment, and is probably
> not very difficult to specify.
>
> However, I'm concerned about two things here:
>
> (a) we don't provide a way to propagate conversations by a "natural
> id" held in some other request parameter - yes, I know we don't
> provide that for JSF either, but in the servlet world it seems even
> more important.
> (b) impact upon the RI timetable.
>
> Today we can provide a portable extension that does conversation
> propagation in servlets, using cid, or natural ids. If we bake
> something into the spec, that becomes a little more difficult.
>
> So I want to know that this is *really* something that we should
> address in this release.


I agree, we don't need to specify conversation propagation for any servlet
request.  Frameworks can handle propagation however is convenient to them.





>
>
> On Thu, May 28, 2009 at 9:32 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
> > Gavin,
> >
> > Since you reached an interlude (however brief it may be), I'd like to
> take
> > the opportunity to reconsider the conversation context lifecycle.
> Currently,
> > the spec states:
> >
> > - For a JSF faces request, the context is active from the beginning of
> the
> > apply request values phase until the response is complete.
> > - For a JSF non-faces request, the context is active during the render
> > response phase.
> >
> > I feel that these boundaries are two narrow. I'll focus first on the
> faces
> > request. In Seam, it's necessary to delay resuming the conversation until
> > the apply request values phase because the conversation id is stored in
> the
> > view root. At one time, the conversation context was even stored in the
> view
> > root, making it even more imperative. But we get a chance to start fresh.
> >
> > There are three factors that call for the boundaries to be extended:
> >
> > - As of JSF 2.0, parts of the component tree is visited in the restore
> view
> > phase, which happens to resolve value expressions bound to UIData
> > components. This triggers a scope not active exception if a
> > conversation-scoped bean is hit.
> > - JSF 2.0 gives us far greater flexibility to control inbound and
> outbound
> > requests. So it's no longer necessary to store the id in the view root.
> The
> > query string would be sufficient (I've already modified Web Beans to
> > prototype this)
> > - Servlets on subsequent requests may want to participate in the
> > conversation (and perhaps even servlet filters)
> >
> > For all of these reasons, I'd like the conversation lifecycle to wrap the
> > entire JSF lifecycle and i'd like the conversation id to be propagated
> using
> > a query string parameter since that's the most universal way of
> propagating
> > state. As a result, custom servlets can read this value and restore the
> > conversation as needed. It's really inconvenient for the conversation id
> to
> > be hidden away into the component tree, aside from being problematic in
> JSF
> > 2.0.
> >
> > Please reconsider. Thanks.
> >
> > -Dan
> >
> > --
> > Dan Allen
> > Senior Software Engineer, Red Hat | Author of Seam in Action
> >
> > http://mojavelinux.com
> > http://mojavelinux.com/seaminaction
> > http://in.relation.to/Bloggers/Dan
> >
> > NOTE: While I make a strong effort to keep up with my email on a daily
> > basis, personal or other work matters can sometimes keep me away
> > from my email. If you contact me, but don't hear back for more than a
> week,
> > it is very likely that I am excessively backlogged or the message was
> > caught in the spam filters.  Please don't hesitate to resend a message if
> > you feel that it did not reach my attention.
> >
> > _______________________________________________
> > webbeans-dev mailing list
> > webbeans-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/webbeans-dev
> >
> >
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090529/10360f4e/attachment.html