On Wed, May 18, 2005 at 04:24:44PM -0400, Hiram Chirino wrote: > > On May 18, 2005, at 9:55 AM, Jeremy Boynes wrote: > > >You will only run into serialization issues if you start making > >incompatible changes to the attribute set for these objects as the > >loader is going to check that the attribute values contained in the > >state are valid for the instance they are being loaded into. This is > >not an issue with Java Serialization but a result of us checking for > >incompatible changes and would also be an issue with any form of XML > >persistence. > > > > Xml persistence would not really have the same issues. As long as the > new builder maintains xml compatibility then the object model that the > builder creates can be radically different. This not the case when you > are reconstructing from a serialized object.
Exactly. The ridged rules of object serialization not only apply to the objects we think of as public objects, but also to all serializable superclasses and innerclasses. Even a small change to a private innerclass N-levels deep will break the entire object graph. We have no good way to prevent breakage at such a microscopic level and no good way to deal with it when it occurs. It's far easier to read in an "old" version of an xml document and upgrade it to the current version of the schema than it is to read in "old" serialized object data and munge it into the current versions of the classes in the object graph. > >Also remember that this will be handled by the configuration manager > >ensuring that the right version of the ActiveMQ codebase is loaded for > >the broker configuration being run. I.e. if you give us a downrev > >configuration we will run it using a downrev broker. > > I agree that this is a non-issue if the user does always deploys of the > new activemq server instead of just "patching" an old activemq jar with > and update. > Right, patching or minor dot upgrading a server without redeploying all the apps is the issue we are trying to solve. -David
