Hi There are some changes in MYFACES-4133 (2.3.x branch) that is required to be discussed on dev list and not on jira.
MYFACES-4133 is all about refactor the existing state API to avoid the java token serialization. I have already stated this is an improvement, not a bug, but since there is a lot of interest in this point I would like to expose the ideas behind the existing API. The change proposed removes these classes: StateTokenProcessor IntIntSerializedViewKey CounterSessionViewStorageFactory IntByteArraySerializedViewKey CounterKeyFactory And the addition of some methods in StateCache: public abstract Object decodeStateToken(FacesContext facesContext, String token); public abstract String encodeStateToken(FacesContext facesContext, Object savedStateObject); public boolean isStatelessToken(FacesContext facesContext, String token) The first problem here is StateCache abstraction. "... provides an interface to separate the state caching operations (saving/restoring) from the renderkit specific stuff that HtmlResponseStateManager should do. ..." Token serialization is HtmlResponseStateManager stuff, specifically related to the render step. StateTokenProcessor was deleted but this interface had the following methods: public abstract Object decode(FacesContext facesContext, String token); public abstract String encode(FacesContext facesContext, Object savedStateObject); public abstract boolean isStateless(FacesContext facesContext, String token); My first question is what's the reason of merge StateTokenProcessor and StateCache? What's the advantage? Well, I can see one, StateCache has a logic related to client-server state saving. Server side state saving uses a counter as token, client side state saving encodes the view state inside the token. But still I think StateTokenProcessor has life on its own. Am I missing something? regards, Leonardo Uribe
