Ceki G�lc� wrote:
At 07:21 PM 8/27/2004, you wrote:
In my application I might be generating a very large number of log events. Most times I don't want to know what's in the blob, but for a small percentage of these messages I may decide that I want to convert the blob into a string (or use some viewer to display what is in the blob). So while I may end up converting it to a human readable string I can delay that until I know I want to look at the event.
OK, you are maybe thinking about a slightly different aspect of the problem. You would like to defer the transformation of the message objet up until the last possible moment. In the case of log4j, it actually converts the message object into a string only when the message needs to be written out. Also, it keeps the reference to the message object for duration of the life cycle of the LoggingEvent object.
In my case I'm thinking about dumping these log events to another machine where they can be manipulatd if necessary. So having to convert the blob into a human readable form initially is not only extra CPU overhead but also network bandwidth.
As for binary properties I could see that would make writing filters more efficnet, instead of doing a ton of string compares I can compare primitive data types.
I don't understand what you mean by binary properties not setProperty.
Sorry, what I meant was currently an event only supports strings in the setProperty method. If it supported other forms of properties (like int, long, float) then filters could be written that would compare against these primitive data types instead of always doing string comparisons. You save CPU time on both the primitive data type to string conversion and in the compare used in the filter.
