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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
