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:[EMAIL PROTECTED]] Sent: 08 June 2001 07:27 To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
