Correction, Cagatay found this. Sigh. It's been one of those days.
Scott
Scott O'Bryan wrote:
Hey guys,
We tracked down the problem that Cathay 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
