On Fri, May 29, 2009 at 5:30 PM, Gavin King <gavin.king(a)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?).
But it seems that you're asking for two changes here:
(1) that the conversation is restored at the beginning of RESTORE_VIEW
This is my primary request. As of JSF 2, there is a lot of activity in the
Restore View phase. It's highly likely that without an active conversation
at that point, developers will find themselves in trouble. We should treat
the restore view phase equally with the other phases. Thus, the conversation
should be started before this phase is entered.
That, of course, rules out the possibility of storing the conversation token
in the UIViewRoot, but I am strongly discouraging that approach looking
(2) that you want some kind of conversation propagation to other servlets
I have received a lot of inquires about whether the conversation is going to
be avaiable in other servlets. I don't really see any reason why it can't be
based on a filter...that would give you control over which requests
participate in conversations right out of the box. And it would furthur
clarify it's relationship with the request scope, in that they at the
shortest map 1-to-1, with the conversation obviously being able to span
multiple requests. But you also can have servlets don't participate in
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.
I would say it's more that if the developer/framework wants to use
conversations in a given request, it would be allowed. Defining the
boundaries as a servlet filter makes the most sense to me. And while it may
not be specified, I think it would be understood that you have to propagate
the conversation token using a mechanism which is portable enough to use in
a filter (meaning not stored using a mechanism specific to JSF). Of course,
the most portable and natural choice is the query string or path info.
Senior Software Engineer, Red Hat | Author of Seam in Action
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.