Re: State Saving in MyFaces Core 1.2

[Simon Kitching <sk...@apache.org>]

Scott O'Bryan schrieb:
> Hey guys,
>
> We tracked down the problem that Cagatay discovered with the Myfaces 
> Portlet Bridge Alpha-3 release and it seems to be related to how 
> MyFaces does it's state saving.  As you may or may not know, because 
> of some servlet dependencies in both the R.I for JSF 1.2 and MyFaces, 
> the Bridge needs to implement it's own ViewHandler.  Pretty much the 
> only functionality of this view handler is replacing the token which 
> is saved in the response with the actual view state key (or whatnot).  
> The bridge has code to handle the ViewState token for both the R.I. 
> and MyFaces, and other JSF implementations can configure a token to 
> use for the token replacement.
>
> The problem we have is that MyFaces only saves the token when the 
> state saving method is set to client.  Server and Javascript state 
> saving just save the tokens they use right up front.  This leaves the 
> Bridge's view handler with no discernable token and we log a warning 
> saying the token can't be found and should be configured.
>
> Looking at it, the logic in MyFaces makes sense to me, because if we 
> have a token which represents state on the server, there is no reason 
> this should need to change.  But it does kind of mess up the bridge's 
> ability to find the right token in it's ViewHandler and as far as I 
> can tell there is no real performance gain to doing things this way 
> since pretty much the whole set of code is executed anyway.
>
> Is there any problem with simply saving the state token every time and 
> then at the end replacing the token with the view-state whether that 
> be a key to a server-side state, a javascript variable, or a 
> client-side state?
>
> Scott
>
It's been a while since I looked at this code.

Am I right in thinking/remembering that using a token means that the 
entire response needs to be buffered in memory, then post-processed when 
the response is complete, and only then streamed to the browser? If so, 
then writing state immediately means that the response does not need to 
be buffered which is a big win in some cases. So forcing token-use when 
the request is a portlet request would be ok, but enabling it for 
non-portlet requests would not be so nice.

Regards,
Simon

Re: State Saving in MyFaces Core 1.2

[Scott O'Bryan <da...@gmail.com>]

Simon, that was my original thought as well.  The thing is, though, that 
we ARE buffering the entire response in memory REGARDLESS of this 
setting.  We just don't seem to actually be replacing tokens for the 
server and javascript state saving methods.  At least that's how this to me.

I do agree that this optimization, if it was indeed an optimization, 
would be preferable to always generating the token.  From a bridge 
perspective though, this makes things really difficult.  For client 
state-saving (and all state saving on the R.I.) we need to do this token 
replacement.  We'd like to handle MyFaces and the R.I. as default 
usecases and allow other JSF implementations to configure their state 
token.  Right now though, if there is no "known" token present in the 
response and a token isn't configured, we need to log a warning every 
request saying that the token in not properly configured.

If we're reluctant to change this logic, perhaps I might be able to pull 
the implementation version of the core out of the manifest API's.  But 
in that case, we would have to agree to a standard set for 
implementation description and a versioning format to put in the 
manifest.  I'd rather not go this route, but I probably can in lieu of 
another choice.

Scott

Simon Kitching wrote:
> Scott O'Bryan schrieb:
>> Hey guys,
>>
>> We tracked down the problem that Cagatay discovered with the Myfaces 
>> Portlet Bridge Alpha-3 release and it seems to be related to how 
>> MyFaces does it's state saving.  As you may or may not know, because 
>> of some servlet dependencies in both the R.I for JSF 1.2 and MyFaces, 
>> the Bridge needs to implement it's own ViewHandler.  Pretty much the 
>> only functionality of this view handler is replacing the token which 
>> is saved in the response with the actual view state key (or 
>> whatnot).  The bridge has code to handle the ViewState token for both 
>> the R.I. and MyFaces, and other JSF implementations can configure a 
>> token to use for the token replacement.
>>
>> The problem we have is that MyFaces only saves the token when the 
>> state saving method is set to client.  Server and Javascript state 
>> saving just save the tokens they use right up front.  This leaves the 
>> Bridge's view handler with no discernable token and we log a warning 
>> saying the token can't be found and should be configured.
>>
>> Looking at it, the logic in MyFaces makes sense to me, because if we 
>> have a token which represents state on the server, there is no reason 
>> this should need to change.  But it does kind of mess up the bridge's 
>> ability to find the right token in it's ViewHandler and as far as I 
>> can tell there is no real performance gain to doing things this way 
>> since pretty much the whole set of code is executed anyway.
>>
>> Is there any problem with simply saving the state token every time 
>> and then at the end replacing the token with the view-state whether 
>> that be a key to a server-side state, a javascript variable, or a 
>> client-side state?
>>
>> Scott
>>
> It's been a while since I looked at this code.
>
> Am I right in thinking/remembering that using a token means that the 
> entire response needs to be buffered in memory, then post-processed 
> when the response is complete, and only then streamed to the browser? 
> If so, then writing state immediately means that the response does not 
> need to be buffered which is a big win in some cases. So forcing 
> token-use when the request is a portlet request would be ok, but 
> enabling it for non-portlet requests would not be so nice.
>
> Regards,
> Simon
>