logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <...@urbanet.ch>
Subject Re: [log4j-dev] Object rendering
Date Fri, 12 Jan 2001 15:58:40 GMT

Hi Anders,

I apologize for not replying earlier. The questions you raise are at the 
heart of the debate. See my comments below.

At 23:39 08.01.2001 +0100, Anders Kristensen  wrote:
>Basically, IMHO, object rendering is, or ought to be, part of the
>existing layout mechanism for logging events.  There are two main parts
>to this
>
>   1. Object renderers exist per Appender (like Layouts) and are
>separately configurable.
>
>   2. Object rendering blends seamlessly with other layout decisions
>
>With the current Object rendering mechanism all objects belonging to the
>same class are rendered by the same renderer. I think that just like we
>have different layouts for different Appenders it is desirable to be
>able to render Objects differently depending on what Category they're
>generated on, or rather the Appender that's used. That's the first item
>above.
>
>The second item means that it's desirable to integrate object rendering
>with LoggingEvent rendering. In Tomcat one might want to log a request
>object. An admin should be able to extract two or more separate pieces
>of information from the request object and mix them up with "generic"
>conversion specifiers from PatternLayout (for example). The way this
>could work is to have a subclass of PatternLayout which recognizes
>additional conversion specifiers specific to Tomcat requests. The admin
>can then have conversion strings like, say, "%z [%d] %u%n" where maybe
>%z is the request method and %u is the request URL. We don't have that
>sort of flexibility with the current mechanism.

True. Currently, the message object that the user passes as an argument is 
transformed very early in the logging process without allowing subsequent 
log4j components to see the message object but just a message *string*. I 
am aware that this is not the smartest way to handle things. However, it 
provides a useful and simple abstraction:

Message objects are transformed to message strings according to a 
transformation rule (ObjectRenderer) specified by the user. This 
transformation is done independently of  any appenders or layouts.


In the alternative approach you propose, it would be  the layout that would 
transform the object. While this provides more degrees of freedom it 
requires more work on the part of layouts. More importantly, layouts and 
their patterns would be associated with a single object type. The 
FruitLayout would format fruits and there would be a need for another 
layout say the VegerableLayout to format vegetables. That would be 
unacceptable.

A better alternative is to allow multiple conversion patterns to be 
associated with a single Layout. For example, the user would specify:

"%d{ISO8601} %h  %t - %m%n"  ---> HttpServletRequest  (%h is the hostname 
of the requester)
"%b %color - %m%n"   ---> my.Company.Car (%b is the car brand and %color 
the car color)
......

This is clearly more complicated than the current solution although it is 
more flexible....

>Another issue is that of remote logging. The SocketAppender currently
>serializes logging events and then just regenerates events on the remote
>logging server, and so, depending on the local confiuration, might
>format and log on the logging server. I like that appraoch a lot and I
>think it would be better if, when Objects are logged, they would be
>serialized (if they're serializable that is), and sent as part of the
>LoggingEvent to the server and regenerated there, i.e. without having
>the generating VM format the Object.

This is another objection that is raised frequently, most notably by Peter 
Donald and also by Andrew Harris. Currently, only the string form of the 
message object is sent to the server. Strings are serializable which is not 
the case of all objects. Moreover, for serialization to succeed, the 
receiving (server) end has to possess a copy of the Serialized class. The 
RMI protocol for example could can  take of that detail...

Assuming we could send the object in serialized form to the other end, what 
advantage would that bring? Log4j is a logging library not a messaging 
middleware. At the end of the day, the server would still format the object 
and display it as a string. What difference does it make to transform at 
the client side rather than at the client? Your point of view would be 
greatly appreciated. Ceki



Mime
View raw message