Unfortunately, there are some headers that are updated on the server, which means that the serialized format for a SpyMessage becomes soon invalid.
Therefore, headers and the message body should be serialized as separate objects and never combined as a single object. This means required changes to the binary format of SpyMessage and loss of backwards compatibility in JBOSS_3_2.
I don't follow your argument?
There is already infrastructure in place in the persistence manager
to update a persistence message.
I don't see why not deserializing the message body (not the properties)
when it arrives on the server will break backwards compatibility.
e.g. a simple solution would be to have a static boolean in SpyMessage that
represents whether serialization should be in server/client mode.
Statics have no affect on serialVersionUUID
i'm a little newbie [in Jboss development, not in development] but i wish to implement that
but what makes me wonder - why do you mention serialVersionUUID? are there any reasons to keep serialVersionUUID unchanged, i.e. we do not have an option to add new fields? why? is serialization in terms of 'java.io.Serializable' used here? i though Externalization is used - i.e. we can pay zero attention on serialVersionUUID?
i guess i do not know smth, could anybody help?
So create a simple test that demonstrates your assertion regarding the effect of the serialVersionUID for Externalizable implementations. When you have done so, let me never again hear you speak of the uselessness of a stable serialVersionUID.
ok, ok - i did my homework, now i know more about
http://jira.jboss.com/jira/browse/JBAS-1342 - i've attached a patch which prevents unneeded deserealizations of SpyTextMessage on server side
[generely, same idea could be used for some header fields - like messageId, for example. i am not sure but seems like there is no need to deserealize messageId on server side]