You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Mike Dougherty <Mi...@san.rr.com> on 2001/06/08 08:27:29 UTC
LoggingEvent serialization
I am trying to pin down what it is (if anything) that needs to be done
to (for) the LoggingEvent serialization.
The Problem: Serialization of the object works fine at present because
the class definition versions are the same. However, at some point in
the future this may not be the case. Therefore, we want to have a way to
make sure the LoggingEvent object remains backward compatible.
Note: This will only be a problem in client/server (or multiple JVM)
environments. Stand alone instances will not need to worry about it
because they will be using the same class definition version.
Ideas so far have been:
1) Research object serialization to see if there is a way to get this
for free (in a manner of speaking).
2) Implement object serialization using XML.
2.1) Internal to the object (I.e. in writeObject())
2.2) External to the object (I.e. in new class
LoggingEventSerializer?)
3) Use a HashMap to store and retrieve properties by name rather than
create getters and setters for newly added properties.
4) Do nothing. Leave it alone and let the user do it the way they
prefer.
Did it miss one? Which one did we decide on?
Personally I prefer #2.2.
Also, I did actually look into #1. If that will ever be changed in
future classes is adding fields (and other minor stuff) then serializing
different versions of the class are not a problem. However, since I
don't believe this will be the case, I don't think we can rely on
default serialization.
/mike
--
******************************************
Mike Dougherty -- Java Software Engineer
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: LoggingEvent serialization
Posted by Mike Dougherty <Mi...@san.rr.com>.
Ceki Gülcü wrote:
>
> ps: See http://www.hta-bi.bfh.ch/~sevem/marco/school/advancedjava/descriptor.html
>
That's good to have. The Sun docs don't explain that very well.
/mike
--
******************************************
Mike Dougherty -- Java Software Engineer
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: LoggingEvent serialization
Posted by Ceki Gülcü <cg...@qos.ch>.
At 10:37 08.06.2001 -0400, you wrote:
>An alternative to adding a version number to each serialized
>LoggingEvent, and thus sending it for each event, is to think of
>SocketAppender as using a protocol with a higher version number. The
>difference is that the version number (which would still signify the
>format of whatever is sent over the connection) is only sent to the
>server when the connection is established. At connection startup the
>client sends protocol name + version number -- much as in HTTP.
>
>If the client appender was to send formatted logging entries as
>discussed recently, the protocol name would be different. This should
>make it a little bit easier for servers to support multiple different
>protocols. We still need to be careful with how LoggingEvent is
>modified, of course.
>
>BTW, isn't the class serialVersionUID already written as part of
>serialized objects?
Yes, but we can't use different values for the serialVersionUID in different class versions because otherwise the serialization mechanism complains about incompatible types even if we make sure that the new and old versions of the class are compatible. Cheers, Ceki
ps: See http://www.hta-bi.bfh.ch/~sevem/marco/school/advancedjava/descriptor.html
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: LoggingEvent serialization
Posted by Ceki Gülcü <cg...@qos.ch>.
Hi Anders,
At 10:37 08.06.2001 -0400, you wrote:
>An alternative to adding a version number to each serialized
>LoggingEvent, and thus sending it for each event, is to think of
>SocketAppender as using a protocol with a higher version number. The
>difference is that the version number (which would still signify the
>format of whatever is sent over the connection) is only sent to the
>server when the connection is established. At connection startup the
>client sends protocol name + version number -- much as in HTTP.
Good point.
>If the client appender was to send formatted logging entries as
>discussed recently, the protocol name would be different. This should
>make it a little bit easier for servers to support multiple different
>protocols. We still need to be careful with how LoggingEvent is
>modified, of course.
Agreed.
>BTW, isn't the class serialVersionUID already written as part of
>serialized objects?
I am sure it is. However, I don't know if it is available to the user. Cheers, Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: LoggingEvent serialization
Posted by Anders Kristensen <ak...@dynamicsoft.com>.
An alternative to adding a version number to each serialized
LoggingEvent, and thus sending it for each event, is to think of
SocketAppender as using a protocol with a higher version number. The
difference is that the version number (which would still signify the
format of whatever is sent over the connection) is only sent to the
server when the connection is established. At connection startup the
client sends protocol name + version number -- much as in HTTP.
If the client appender was to send formatted logging entries as
discussed recently, the protocol name would be different. This should
make it a little bit easier for servers to support multiple different
protocols. We still need to be careful with how LoggingEvent is
modified, of course.
BTW, isn't the class serialVersionUID already written as part of
serialized objects?
Cheers,
Anders
Ceki Gülcü wrote:
>
> Hello Mike,
>
> The only way I can think of solving this problem is by adding version control in side the LoggingEvent serialization code. For example, in version t0, the version number t0 is written to the stream before other data. On the retrieving end, LoggingEvent version t0 checks that the incoming LoggingEvent is a t0 and happily reads it. There is a less fortunate case which I will come back to later.
>
> When version t1 comes along, it writes its version number, t1, to the stream before other data. On the receiving end, LoggingEvent version t1 is coded such that it is capable of reading LoggingEvents of version t1 *and* also t0.
>
> Similarly, version tN is capable of reading version t0, t1, ..., tN-1, tN.
>
> This allows a given version to read previous versions but not future versions. In others words, servers (which only read LoggingEvents) can be considers backward compatible with clients but not future compatible. In situations where there are many clients but only few servers, updating the server to the latest version should solve LoggingEvent versioning problems.
>
> This approach isolates the versioning problem to the LoggingEvent class. However, it might well be the case that the code using the LoggingEvent depends on features only in version tX. Thus, it wont be compatible with version tX-1 even of LoggingEvent version tX can read LoggingEvent version tX-1. We are back to the starting point...
>
> I don't think there is a silver bullet to the LoggingEvent version compatibility problem. Each modification to the LoggingEvent class must be studied carefully with compatibility in mind. That hasn't been the case up until now.
>
> Given the increasing popularity of log4j, we have made a serious effort with respect to backward compatibility of our public user interface. I am quite happy about the results. I think with some effort we can repeat the same success with respect to the LoggingEvent class. Regards, Ceki
>
> At 23:27 07.06.2001 -0700, you wrote:
> >I am trying to pin down what it is (if anything) that needs to be done
> >to (for) the LoggingEvent serialization.
> >
> >The Problem: Serialization of the object works fine at present because
> >the class definition versions are the same. However, at some point in
> >the future this may not be the case. Therefore, we want to have a way to
> >make sure the LoggingEvent object remains backward compatible.
> >
> >Note: This will only be a problem in client/server (or multiple JVM)
> >environments. Stand alone instances will not need to worry about it
> >because they will be using the same class definition version.
> >
> >Ideas so far have been:
> >
> >1) Research object serialization to see if there is a way to get this
> >for free (in a manner of speaking).
> >
> >2) Implement object serialization using XML.
> > 2.1) Internal to the object (I.e. in writeObject())
> > 2.2) External to the object (I.e. in new class
> >LoggingEventSerializer?)
> >
> >3) Use a HashMap to store and retrieve properties by name rather than
> >create getters and setters for newly added properties.
> >
> >4) Do nothing. Leave it alone and let the user do it the way they
> >prefer.
> >
> >Did it miss one? Which one did we decide on?
> >
> >Personally I prefer #2.2.
> >
> >Also, I did actually look into #1. If that will ever be changed in
> >future classes is adding fields (and other minor stuff) then serializing
> >different versions of the class are not a problem. However, since I
> >don't believe this will be the case, I don't think we can rely on
> >default serialization.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
--
Anders Kristensen
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: LoggingEvent serialization
Posted by Ceki Gülcü <cg...@qos.ch>.
Hello Mike,
The only way I can think of solving this problem is by adding version control in side the LoggingEvent serialization code. For example, in version t0, the version number t0 is written to the stream before other data. On the retrieving end, LoggingEvent version t0 checks that the incoming LoggingEvent is a t0 and happily reads it. There is a less fortunate case which I will come back to later.
When version t1 comes along, it writes its version number, t1, to the stream before other data. On the receiving end, LoggingEvent version t1 is coded such that it is capable of reading LoggingEvents of version t1 *and* also t0.
Similarly, version tN is capable of reading version t0, t1, ..., tN-1, tN.
This allows a given version to read previous versions but not future versions. In others words, servers (which only read LoggingEvents) can be considers backward compatible with clients but not future compatible. In situations where there are many clients but only few servers, updating the server to the latest version should solve LoggingEvent versioning problems.
This approach isolates the versioning problem to the LoggingEvent class. However, it might well be the case that the code using the LoggingEvent depends on features only in version tX. Thus, it wont be compatible with version tX-1 even of LoggingEvent version tX can read LoggingEvent version tX-1. We are back to the starting point...
I don't think there is a silver bullet to the LoggingEvent version compatibility problem. Each modification to the LoggingEvent class must be studied carefully with compatibility in mind. That hasn't been the case up until now.
Given the increasing popularity of log4j, we have made a serious effort with respect to backward compatibility of our public user interface. I am quite happy about the results. I think with some effort we can repeat the same success with respect to the LoggingEvent class. Regards, Ceki
At 23:27 07.06.2001 -0700, you wrote:
>I am trying to pin down what it is (if anything) that needs to be done
>to (for) the LoggingEvent serialization.
>
>The Problem: Serialization of the object works fine at present because
>the class definition versions are the same. However, at some point in
>the future this may not be the case. Therefore, we want to have a way to
>make sure the LoggingEvent object remains backward compatible.
>
>Note: This will only be a problem in client/server (or multiple JVM)
>environments. Stand alone instances will not need to worry about it
>because they will be using the same class definition version.
>
>Ideas so far have been:
>
>1) Research object serialization to see if there is a way to get this
>for free (in a manner of speaking).
>
>2) Implement object serialization using XML.
> 2.1) Internal to the object (I.e. in writeObject())
> 2.2) External to the object (I.e. in new class
>LoggingEventSerializer?)
>
>3) Use a HashMap to store and retrieve properties by name rather than
>create getters and setters for newly added properties.
>
>4) Do nothing. Leave it alone and let the user do it the way they
>prefer.
>
>Did it miss one? Which one did we decide on?
>
>Personally I prefer #2.2.
>
>Also, I did actually look into #1. If that will ever be changed in
>future classes is adding fields (and other minor stuff) then serializing
>different versions of the class are not a problem. However, since I
>don't believe this will be the case, I don't think we can rely on
>default serialization.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org