logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Bushman <...@traxel.com>
Subject Re: LoggingEvent Serialization
Date Tue, 20 Nov 2001 01:04:15 GMT
readResolve sounds ideal, I'll play around with it
a bit and see what I can come up with.

On 1.2 v. 1.1. IMHO the question should be "How can
Log4j be of the most value to the most developers?"

The number of people who will lose value by Log4j
1.2 and higher not being compatible with JDK 1.1
is small and rapidly declining. 1.1.3 will still
be a solid, viable solution for Java 1 apps.

The increase in quality and power from JDK 1.1
to 1.2 is enormous. The superior API means cleaner
code. In turn this results in better performance,
maintainability, and robustness.

IMHO there's no question that the move to 1.2 is
appropriate (but I always have been an early
adopter, YMMV).

On Tue, 20 Nov 2001, Ceki Gulcu wrote:

> Robert,
> 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
> discovered.
> 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
> >http://traxel.com/tools/LoggingEvent.java
> >
> >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>

  Who owns your data?
    Proprietary protocols and file formats are dangerous.

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