Hi! >> AFAIK there is no way in readObject to get the serialVersionUID of the >> stored object, is there a way? >> > > I'm not sure. Why would you want to? > > >> I'd generate the serialVersionUID with any number and use a second local >> version which will be written first to the the stream. >> That way, we can react in readObject appropriate. >> A little bit more complex, but robust about changes. >> > > Sorry, I don't understand. > > You're thinking perhaps that the readObject method could detect the > version of data being read in, and set certain fields to default values > if the object format is old, else read them from the stream? Exactly. This is what I do often.
> I guess > that is possible but I don't see why Orchestra would need to get that > tricky... > On the other hand, I do not understand what the serialVersionUID is worth implementing it when we do not gain anything additional other than make our IDE shut-up. > Can we perhaps start with the default serialVersionUID behaviour, and > add this when necessary? > Skimming through the source showed me that none of the serialization cases are really there to do "classic serialization" - just to make the container happy. So - yes - there is no problem starting with the default behaviour :-) > There is one apparently tricky case, the ConversationManager. For the > other classes, is it ok to add serialVersionUID? > > For ConversationManager, I see that custom serialization (readObject et > al) has currently been implemented, with the comment > //we just implement it to make it work with distributed sessions > Does this code actually work with distributed sessions? It looks to me > like any access to this class on a machine other than the one it was > created on will cause exceptions due to things like > conversationContexts and conversationManager being null.. > You are right, it does NOT work with distributed sessions, but it is required to avoid this nasty exception if you put a not-serializable bean into the session scope. As of now, using Orchestra requires you to use sticky sessions (a session bound to a specific tomcat instance). The problem is, that I do not know yet if it is possible to serialize all the database session state of the used ORM mapper. I thought about to solve this once we have to cross this bridge. For now, it is assured that, if the http session has to switch to another node (e.g. due to server failure) the user just has to start over the current conversation. Ciao, Mario
