Anyway, a non-trivial amount of thinking went into the implementation of the equals() method. In the absence of a malevolent adversary, it is also correct although only probabilistically so. Its only downside is the addition of the static sequenceCount field and the sequenceNumber field in LoggingEvent.
Besides helping in the efficient implementation of the equals() method (needed by Chainsaw), the sequenceNumber field in LoggingEvent also greatly simplifies the implementation of receivers needing to repeatedly query a data store, e.g. DBReceiver.
So imho sequenceCount provides real added value.
At 10:11 PM 12/28/2004, you wrote:
At 09:49 PM 12/28/2004, Curt Arnold wrote:The point that I was trying to make and which I still think is valid despite my mistaken analysis of the hashCode function, is that it is better to have Chainsaw to make whatever comparison it thinks is appropriate for its filtering needs and avoid having to worry about maintaining the equals contract and having a hashCode function that results in good performance if LoggingEvents are added to a HashTable.
-- 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]
