Nice.
I think thats actually more important than we've been giving it credit for in this thread!

- Brill Pappin





On 12-Apr-09, at 12:51 AM, Luther Baker wrote:

I don't know much about it ... but would something like Terracotta
use/require/leverage the serialVersionUID for something not so obvious in
normal, singly homed deployments?

I think I understand that it helps confirm or explicitly 'version'
components that might be working together or across, say, JVM boundaries - but it seems like, if not explicitly provided, a default value is built
automatically and, unless I want an older version to work with a newer
version, I am fine just letting that happen.

In fact, unless I am really abiding by serialVersionUID rules (changing it
explicitly - every time I make a relevant, corresponding change to the
containing class) - I'm not really gaining any functionality that the
runtime can't already do. In fact, unless rigorously maintained, it seems I could likely end up with two different compiled versions with identical, explicit serialVersionUIDs - which surely seems worse then leaving it alone?

-Luther


On Sat, Apr 11, 2009 at 10:56 PM, Adriano dos Santos Fernandes <
adrian...@uol.com.br> wrote:

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



Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to