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