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
- State Saving in MyFaces Core 1.2 Scott O'Bryan
-
