RE: LoggingEvent serialisation

[Mark Douglas <Ma...@systemsunion.com>]

Hi,

I can not provide a solution here, but I think option 2.1 and 2.2 are out of
the question.  The reason being that LoggingEvent data would balloon in size
and logging performance would slow to an unacceptable pace.

LoggingEvent already has 'size limiting' code in an attempt to keep things
small and fast (Priority serialised by value for example).  XML bloats any
data that is contained.  Also, the server would need to parse the incoming
XML document - not a very quick process (in comparison to the current
method).

I think Ceki is on the right track with using version information  before
each LoggingEvent (I use it to great effect in other code).  The only thing
you need to ensure is that the server has the most up-to-date version of
LoggingEvent that copes with all previous versions of the serialised data.
Surely that's not too difficult for most people to ensure?

This way we keep the performance AND we have backward compatibility.

Mark Douglas
Systems Union Group plc.

-----Original Message-----
From: Mike Dougherty [mailto:MikeD@san.rr.com]
Sent: 08 June 2001 07:27
To: log4j-dev@jakarta.apache.org
Subject: 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

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org