<br><br><div class="gmail_quote">On Fri, May 29, 2009 at 5:30 PM, Gavin King <span dir="ltr"><<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
OK, Dan, I'll have to respect your judgment on this because I'm not up<br>
to date on how this stuff works in JSF2.<br>
<br>
So I'm happy to make changes with respect to JSF conversation<br>
propagation rules if it doesn't disrupt/delay the RI team (Pete,<br>
WDYT?) and if there are no objections from the EG (anyone?).</blockquote><div><br>No, no objection here. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
But it seems that you're asking for two changes here:<br>
<br>
(1) that the conversation is restored at the beginning of RESTORE_VIEW</blockquote><div><br>Is there any reason we can't require the conversation to be restored before the invocation of any servlet filter? <br> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
(2) that you want some kind of conversation propagation to other servlets<br>
<br>
Change (1) seems a pretty straightforward change.<br>
<br>
So we get to (2).<br>
<br>
Currently we don't even have a built-in conversation context in<br>
servlets and we would need some kind of additional rules surrounding<br>
conversation propagation between servlets. I think what you are<br>
suggesting is that the conversation is propagated whenever there is a<br>
request parameter named "cid" containing the conversation id, and that<br>
it is the user's responsibility to pass it along through the view.<br>
That doesn't sound unreasonable to me at this moment, and is probably<br>
not very difficult to specify.<br>
<br>
However, I'm concerned about two things here:<br>
<br>
(a) we don't provide a way to propagate conversations by a "natural<br>
id" held in some other request parameter - yes, I know we don't<br>
provide that for JSF either, but in the servlet world it seems even<br>
more important.<br>
(b) impact upon the RI timetable.<br>
<br>
Today we can provide a portable extension that does conversation<br>
propagation in servlets, using cid, or natural ids. If we bake<br>
something into the spec, that becomes a little more difficult.<br>
<br>
So I want to know that this is *really* something that we should<br>
address in this release.</blockquote><div><br>I agree, we don't need to specify conversation propagation for any servlet request. Frameworks can handle propagation however is convenient to them.<br><br>
<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div><div></div><div class="h5"><br>
On Thu, May 28, 2009 at 9:32 PM, Dan Allen <<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>> wrote:<br>
> Gavin,<br>
><br>
> Since you reached an interlude (however brief it may be), I'd like to take<br>
> the opportunity to reconsider the conversation context lifecycle. Currently,<br>
> the spec states:<br>
><br>
> - For a JSF faces request, the context is active from the beginning of the<br>
> apply request values phase until the response is complete.<br>
> - For a JSF non-faces request, the context is active during the render<br>
> response phase.<br>
><br>
> I feel that these boundaries are two narrow. I'll focus first on the faces<br>
> request. In Seam, it's necessary to delay resuming the conversation until<br>
> the apply request values phase because the conversation id is stored in the<br>
> view root. At one time, the conversation context was even stored in the view<br>
> root, making it even more imperative. But we get a chance to start fresh.<br>
><br>
> There are three factors that call for the boundaries to be extended:<br>
><br>
> - As of JSF 2.0, parts of the component tree is visited in the restore view<br>
> phase, which happens to resolve value expressions bound to UIData<br>
> components. This triggers a scope not active exception if a<br>
> conversation-scoped bean is hit.<br>
> - JSF 2.0 gives us far greater flexibility to control inbound and outbound<br>
> requests. So it's no longer necessary to store the id in the view root. The<br>
> query string would be sufficient (I've already modified Web Beans to<br>
> prototype this)<br>
> - Servlets on subsequent requests may want to participate in the<br>
> conversation (and perhaps even servlet filters)<br>
><br>
> For all of these reasons, I'd like the conversation lifecycle to wrap the<br>
> entire JSF lifecycle and i'd like the conversation id to be propagated using<br>
> a query string parameter since that's the most universal way of propagating<br>
> state. As a result, custom servlets can read this value and restore the<br>
> conversation as needed. It's really inconvenient for the conversation id to<br>
> be hidden away into the component tree, aside from being problematic in JSF<br>
> 2.0.<br>
><br>
> Please reconsider. Thanks.<br>
><br>
> -Dan<br>
><br>
> --<br>
> Dan Allen<br>
> Senior Software Engineer, Red Hat | Author of Seam in Action<br>
><br>
> <a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br>
> <a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br>
> <a href="http://in.relation.to/Bloggers/Dan" target="_blank">http://in.relation.to/Bloggers/Dan</a><br>
><br>
> NOTE: While I make a strong effort to keep up with my email on a daily<br>
> basis, personal or other work matters can sometimes keep me away<br>
> from my email. If you contact me, but don't hear back for more than a week,<br>
> it is very likely that I am excessively backlogged or the message was<br>
> caught in the spam filters. Please don't hesitate to resend a message if<br>
> you feel that it did not reach my attention.<br>
><br>
</div></div><div class="im">> _______________________________________________<br>
> webbeans-dev mailing list<br>
> <a href="mailto:webbeans-dev@lists.jboss.org">webbeans-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/webbeans-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/webbeans-dev</a><br>
><br>
><br>
<br>
<br>
<br>
</div><font color="#888888">--<br>
Gavin King<br>
<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a><br>
<a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>
<a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>
<a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
webbeans-dev mailing list<br>
<a href="mailto:webbeans-dev@lists.jboss.org">webbeans-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/webbeans-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/webbeans-dev</a><br>
</div></div></blockquote></div><br>