logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <c...@qos.ch>
Subject Re: LoggingEvent Serialization
Date Mon, 19 Nov 2001 23:17:54 GMT

Sorry, I meant dropping backward compatibility for JDK 1.1 since ObjectInputStream#readFields
requires JDK 1.2. 

At 00:14 20.11.2001 +0100, you wrote:
>I also noticed that ObjectInputStream#readFields method was introduced in
>JDK 1.2. I have no qualms about dropping support for JDK 1.2. However, if
>that is going to be the case, then  the Priority class can be made 
>serializable while still conserving the flyweight property by implementing 
>the readResolve method:
>Java Object Serialization Specification 
>3.6 The readResolve Method 
>For Serializable and Externalizable classes, the readResolve method
>allows a class to replace/resolve the object read from the stream
>before it is returned to the caller. By implementing the readResolve
>method, a class can directly control the types and instances of its
>own instances being deserialized. The method is defined as follows:
>        ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException;
>The readResolve method is called when ObjectInputStream has read an
>object from the stream and is preparing to return it to the
>caller. ObjectInputStream checks whether the class of the object
>defines the readResolve method. If the method is defined, the
>readResolve method is called to allow the object in the stream to
>designate the object to be returned. The object returned should be of
>a type that is compatible with all uses. If it is not compatible, a
>ClassCastException will be thrown when the type mismatch is
>For example, a Symbol class could be created for which only a single
>instance of each symbol binding existed within a virtual machine. The
>readResolve method would be implemented to determine if that symbol
>was already defined and substitute the preexisting equivalent Symbol
>object to maintain the identity constraint. In this way the uniqueness
>of Symbol objects can be maintained across serialization.
>This is exactly the semantics we want for the Priority class! 
>Regards, Ceki
>At 23:19 18.11.2001 -0500, you wrote:
>>I'm pretty happy with the new version posted at
>>It's now reading 1.1.3 and 1.2, and deserialization
>>has been refactored to a satisfactory level.
>>Known Issues:
>> - It has not been rigorously tested.
>> - startTime is static, so when you serialize,
>>   then compare startTime to timeStamp you get
>>   a meaningless number (startTime is coming
>>   from the server, timeStamp is coming from
>>   the client). This could be solved by making
>>   startTime an instance parameter, and initializing
>>   it to application start time in the constructor
>>   (have a class parameter systemStartTime).
>>   Then readObject could simply overwrite the
>>   instance parameter with the serialized value.
>>   This is, of course, assuming that the objective
>>   is to be able to tell how long into it's life
>>   the application was when the log was generated.
>>To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>
>To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

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

View raw message