cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Durchholz, Joachim" <Joachim.Durchh...@hennig-fahrzeugteile.de>
Subject RE: Serialization warnings
Date Fri, 15 Jun 2012 12:36:54 GMT
> On 15/06/12 6:34pm, Durchholz, Joachim wrote:
>> Don't take this as an expert opinion, but since subclasses contain all 
>> member fields of the superclass, I'd expect that a subclass needs to 
>> have a changed SerialVersionUUID if the superclass changes.
>>
>> Testing this aspect might be in order.
> 
> My question would be: test what?

Test whether changing the superclass in a serialization-breaking way, without updating the
subclass' serialVersionUID, causes a deserialization failure.

> In the real world are SerialVersionUUID particularly useful for Cayenne
> entities? With Cayenne ROP, I've never seen any code in Hessian which
> pays any attention to the version.

Java's @Serializable mechanism reports mismatches via exceptions.
So the absence of any special code means that everything is as it should be.

Assuming those @Serializable annotations are there to make Hessian work, that is.
If Hessian does not use Java's standard serialization, I don't see the point of those @Serializable
and serialVersionUID declarations in the first place.

> Is this more useful with a cluster of application servers and different
> instances running different versions of the code? Are there are specific
> use cases where Cayenne entities would be involved?

Yes, if client and server disagree about the format of the serialized data.
This could happen if the entity classes were updated on one side but not on the other (due
to some roll-out mishap, for example).
Sounds like fail-fast is a good idea in such a scenario.

Mime
View raw message