- Servlets on subsequent requests may want to participate in the conversation (and perhaps even servlet filters)

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?). But it seems that you're asking for two changes here: (1) that the conversation is restored at the beginning of RESTORE_VIEW (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. On Thu, May 28, 2009 at 9:32 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev > > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

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?).

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

(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.

On Thu, May 28, 2009 at 9:32 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev > > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

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?). But it seems that you're asking for two changes here: (1) that the conversation is restored at the beginning of RESTORE_VIEW

(2) that you want some kind of conversation propagation to other servlets

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.