Since Tapestry makes it easy to persist application state by using the @Persist annotation, I tend to have a habit of using mutable state objects and then stumbling on problems when changing these mutable persisted values do not result in updates to the underlying session store.
Here's a sample page class:
On the page template, we simply display the current state and an action link to call the onActionFromChangeState event. Everything seems to work - the state object (List) is lazily initialized and new items are appended to it.
Long story short, Tapestry does not detect the changes to a mutable persisted state object. Unfortunately, the way HTTP sessions are usually implemented in many servlet containers, changes to the mutable state are still persisted (bypassing the Tapestry's persistent field invalidation mechanism). This can cause unexpected and hard-to-trace problems later, when trying to switch the persistence strategy for a specific state variable, e.g. from the session to the client strategy.
For instance, here we try to change the previous sample to use client-side persistence instead:
But when calling the onActionFromChangeState, nothing seems to happen. The state is transferred from the server to the client and back, but this always contains an empty List. This corresponds to the empty List initialized on the first render request.
To demonstrate that this is really the case, we can use a simple hack:
Now the changeState action works once again, since the PersistentFieldConduit responsible for recording the change of the field value is used. Although this kind of a "hack-y" approach works, the moral of the story seems to be quite clear - be very careful when persisting mutable values.
