Yep, it's not a bug but a good improvement. Personally i would only do it in 2.3.
As i already explained, i removed those classes as "sequence" view-id generator must not be used anymore. My reasons to merge both classes are that we already have a artifact which handles client side state, and we already have a artifact which handles server side state. Maybe "Cache" is not a 100% perfect name but it's ok IMO. We could still search for another name, which would be a very very small improvement. There is no reason to e.g. use a ClientSide-StateTokenProcessor with a ServerSide-StateCache. Thereis one big mechanism for server-side state and one for client-side state. How to render it and how to create/restore it, are both sides of the medal. 2017-12-19 21:09 GMT+01:00 Leonardo Uribe <[email protected]>: > 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 > > >
