Absolutely right. Never use serialisation for persistence. If the code changes and the reader/writer are not in sync, then there will be failure while reading the data. Worse, since it's binary, there isn't a whole lot you can do other than back off to the version of code prior to the change. It's useful in very few cases like sending data across a socket and that too is safe only if the client and server are *in the same jar file*. Not to say that it can't be safe if they were in different jar files, but this is the only way to guarantee that you don't have mismatched code.
What we have done is read/write data in XML. Even if the code changes, the XML file can be read and fixed to add/remove elements that were changed. On Fri, 18 Jul 2003 09:58:44 +0100, Nijjhar, Baljeet wrote: >Hi, I've heard things about using serialisation such as it's not the same >from one JDK version to another which makes me wonder if it should be >avoided for maintenance/compatibility reasons. >I wouldn't even know what the issues are with storing and organising >serialised data, as I know very little about this area. Can you shed a >little light maybe?? What kind of storage is typically used? >Thanks, Baljeet > >-----Original Message----- >From: Thomas Muller [mailto:[EMAIL PROTECTED] >Sent: 18 July 2003 09:51 >To: Log4J Users List >Subject: RE: Reading events > > >The LoggingEvent implements the java.io.Serializable interface, so you're >free to dump it to any storage media of your discretion and read it back as >a java object. > >The SocketAppender uses this technique already; the LoggingEvents are >serialised and streamed over a socket to a SocketServer. > >It's easy to write an appender that serializes the LoggingEvents to a >stream, it's the storage capacity and the organization of it that's going to >be your major concern. > >Hope this helps, > >-- > >Thomas > > >| -----Original Message----- >| From: Nijjhar, Baljeet [mailto:[EMAIL PROTECTED] >| Sent: 18 July 2003 09:35 >| To: 'Log4J Users List' >| Subject: Reading events >| >| >| Hi >| Does anyone know if there are any methods to read back a log >| record once it >| has been written to an appender? In general, does anyone have any bright >| ideas for being able to store logs in a persistent store such >| that they can >| be read back as objects (LoggingEvents or whatever), and therefore be able >| to be manipulated according to certain crieria (e.g. check their >| timestamps >| so that you only retrieve ones within a certain range)? I'm >| trying to avoid >| the overhead of creating a database for logging and reading log records >| from, but it doens't seem that you can read the records back that you've >| written using log4j. >| Thanks, Baljeet Nijjhar >| >| >| This e-mail and any attachment is for authorised use by the >| intended recipient(s) only. It may contain proprietary material, >| confidential information and/or be subject to legal privilege. >| It should not be copied, disclosed to, retained or used by, any >| other party. If you are not an intended recipient then please >| promptly delete this e-mail and any attachment and all copies and >| inform the sender. Thank you. >| >| --------------------------------------------------------------------- >| To unsubscribe, e-mail: [EMAIL PROTECTED] >| For additional commands, e-mail: [EMAIL PROTECTED] >| >| > > > >************************************************************************* >Copyright ERA Technology Ltd. 2003. (www.era.co.uk). All rights reserved. >The information supplied in this Commercial Communication should be treated >in confidence. >No liability whatsoever is accepted for any loss or damage >suffered as a result of accessing this message or any attachments. > >________________________________________________________________________ >This email has been scanned for all viruses by the MessageLabs Email >Security System. For more information on a proactive email security >service working around the clock, around the globe, visit >http://www.messagelabs.com >________________________________________________________________________ > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > >This e-mail and any attachment is for authorised use by the intended recipient(s) >only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > Regards Milind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
