At 12:09 AM 5/12/2004, Paul Smith wrote:
>
>    private void readObject(ObjectInputStream ois)
>           throws java.io.IOException, ClassNotFoundException {
>      ois.defaultReadObject();
>      readLevel(ois);
>
>      // Make sure that location info instance is set.
>      if (locationInfo == null) {
>        locationInfo = LocationInfo.NA_LOCATION_INFO;   <---
> this is noteworthy
>      }
>    }

Would it be simpler to make this the default value for a newly constructed
LoggingEvent then, rather than rely on the readObject method, and EVERY
Receiver impl to have to think about this?  I don't like null values, so
making the declaration of the locationInfo property self initialise to
LocationInfo.NA_LOCATION_INFO makes more sense, unless I am misinterpretting
something.

cheers,

Paul Smith

Your interpretation is fine except for one detail. LocationInfo is initialized lazily. Thus, if LocationInfo is null, it is computed and created on the fly.

The LoggingEvent.getLocationInformation method used to read:

  public LocationInfo getLocationInformation() {
    if (locationInfo) {
      locationInfo = new LocationInfo(new Throwable(), fqnOfLoggerClass);
    }
    return locationInfo;
  }

I recently changed it to:

  public LocationInfo getLocationInformation() {
    if (locationInfo == null && fqnOfLoggerClass != null) {
      locationInfo = new LocationInfo(new Throwable(), fqnOfLoggerClass);
    }
    return locationInfo;
  }

Thus, when fqnOfLoggerClass is null, locationInfo is not computed
automatically. This protects against the case where locationInfo is
automatically but erroneously computed after serialization. (We can't
compute caller's location info for a deserialized event. It way too
late for that.)

I not very satisfied with the current approach either. It works as
long as every receiver implementation takes care of the details. Just
as importantly, the problem repeats itself with other LoggingEvent
fields as well. I'd love to see a better pattern for addressing both
the lazy initialization issue and the (correctly!) read after
serialization issue.

In the absence of a better approach, I'd like to document the steps
required to be taken by receivers in the "contract" of the
LoggingEvent class.

ps: I am using the term "serialisation" rather loosely. It's not only
Java serialisation. An event written to a DB table(s) or to a file in
XML format is also referred to as "serialized".

--
Ceki G�lc�

For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to