Brill Pappin wrote:
Actually i don't think a missing one will cause that to fail unless
there are a lot of incompatible changes.
Just one incompatible change of class stored in the session and it will
not be deserialized.
However... even if it does matter, *in no way* should anyone depend on
a serialized session to store data.... if your app can't recover from
a clean session, you have bigger problems than not adding a
serialVersionId.
Hum? What about stateful pages, which is the Wicket "market"?
If you can control your serial IDs, you have the chance of write custom
deserializers. That does not means you can't with an absent ID, but
AFAIU just the inclusion of one field and it will change making the
deserialization fail.
Adriano
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
