RE: cvs commit: logging-log4j/src/java/org/apache/log4j/pattern C lassNamePatternConverter.java LineLocationPatternConverter.java FullLocat ionPatternConverter.java FileLocationPatternConverter.java MethodLocation PatternConverter.java

[Paul Smith <Pa...@lawlex.com.au>]

> 
>    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

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

RE: cvs commit: logging-log4j/src/java/org/apache/log4j/pattern C lassNamePatternConverter.java LineLocationPatternConverter.java FullLocat ionPatternConverter.java FileLocationPatternConverter.java MethodLocation PatternConverter.java

[Ceki Gülcü <ce...@qos.ch>]

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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org