At 11:01 PM 1/10/2005, Curt Arnold wrote:
In the original message, I outlined two approaches and their perceived drawbacks. One was just replacing sequenceCount with the value of super.hashCode. This would likely work okay, but the short-lifetime of LoggingEvent's might result in recurring values for hashCode and that would have to be investigated.
The hashCode is also computed over the timestamp. I'd expect the following version to give entirely satisfactory results.
public int hashCode() {
return (int)((timeStamp & 0xFFFFFFFF) ^ (eventId));
}My favored approach in that message was a full value comparison implementation of equals and hashCode. I had not expected the requirement that identical but distinct logging messages not compare as equal. To address that short-coming, you could still add the eventID and use that in a full value comparison implementation of equals.
If we pool LoggingEvent objects then successive events will have the same address and hence the same eventId.
I am not 100% sure about the safety of eventId=super.hashCode(). With hundreds of events created and GCed every millisecond, the probability of two events having the same eventId seems non-negligible. We'd need to check for more fields in LoggingEvent.equals() but I guess that's exactly what you are suggesting. :-)
It may be adequate for equals and hashCode to only check the timestamp, event id and message text. I think it would be very very rare that two messages in the wild would have duplicate values for all three, and if they did having Chainsaw drop one as a duplicate would not be a significant issue.
Except if we pool LoggingEvent objects
I'll take a stab at just the Builder rework. Do you have any objections to my committing it if it seems pretty straightforward and passes all the tests?
No objections as long as the Category.forcedLog method remains unchanged. When logging an event, we should not build two objects (LoggingEventBuilder+LoggingEvent) instead of the current one (LoggingEvent).
Have you considered adding support for LoggingEvent object pooling?
-- Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
