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
