On Friday 13 December 2002 01:52, Ceki Gülcü wrote:
> At 09:34 12.12.2002 -0800, you wrote:
> >Dan,
> >
> >My only concern is the changing of LoggingEvent. This object gets
> >serialized across sockets from one log4j process to another, so
> > maintaining some level of compatibility between different log4j versions
> > is important. Won't adding a new private member break serialization
> > between versions? Anyone?
>
> No, adding fields does not break backward compatibility in the sense that
> clients version 'n' can send to server version 'n+1' where the difference
> between n and n+1 is the addition of an extra field. I don't remember what
> happens when n+1 sends to n.
Adding private members and maintaining compatibility in both directions is
more or less automatic;
v1 -> v2, the member field in v2 is filled with null for objects, false for
boolean and 0 for numerics.
v2 -> v1, the member field is transferred but ignored by v1.
To allow for better v1->v2 handling, one should do explicit deserialization by
readObject method;
private void readObject( ObjectInputStream in )
throws IOException, ....
{
in.defaultReadObject(); //takes care of most
if( m_NewMember == null )
m_NewMember = "Not serialized."
}
kind of thing....
Niclas
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
