Hi, We should balance the performance aspect versus the requirement for serialization compatibility. I think the latter is a nice to have, but by no means an essential feature. I think the former is imperative for log4j as it is for any logging system. If we can get the serialization compatibility without losing performance of the related classes, that's cool.
Yoav Shapira http://www.yoavshapira.com >-----Original Message----- >From: Niclas Hedhman [mailto:[EMAIL PROTECTED] >Sent: Sunday, December 05, 2004 4:36 AM >To: Log4J Developers List >Subject: Re: LoggingEvent serialization compatibility between 1.2 and 1.3 > >On Sunday 05 December 2004 16:20, Scott Deboy wrote: >> I haven't tried sending events from log4j 1.3 to log4j 1.2.8, but I doubt >> deserialization would work, without more changes to serialization logic. >> >> In 1.3, LoggingEvent contains a new field: >> long sequenceNumber >> The 1.2.8 code wouldn't know what to do with it. > >Being a somewhat expert on serialization, I can offer the expert insight >you >may require. > >For the above; Adding a field is, without further action, an incompatible >serialization change, because it changes the signature of the class. > >However, if both classes have the same serialVerUID, it is a compatible >change, i.e. the field will be ignored from the stream. > >Since the 1.2 classes already exists, and you want to remain comptible in >1.3, >you will need to run the serialtool against the old class and put in the >generated value in the 1.3 class. If there has been serialization >incompatible changes with the 1.2.x line, you will only get compatibility >with one of those, preferably the last one. This can be checked by running >serialtool against each of the older versions, and see if the same number >is >generated. > >For NEW serializable classes, just put in a serialVerUID=1. That number >only >needs to be incremented/changed when there is a serialization incompatible >change. > >Furthermore, it is recommended that you provide your own readObject and >writeObject methods for each of the serializable classes to get better >control of what is going and more easily handle the process. For instance, >a >missing field from 1.2 being deserialized in 1.3 will contain a field >specific default value (0 for int, null for Objects), which may not be >accurate. > > >Cheers >Niclas >-- > +------//-------------------+ > / http://www.dpml.net / > / http://niclas.hedhman.org / >+------//-------------------+ > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
