Sorry, "getSequenceCount" was a short-hand reference to a fairly involved thread about a month ago. A sequence number is currently being used as a logging event identifier, but there are likely better ways of meeting the actual requirements. The thread is pretty long and convoluted, most of it was trying to figure out what the actual requirements were. Having a monotonically increasing message sequence number wasn't one of them. Having an implementation of equals and hasCode were requirements (from the Chainsaw team).
I don't see why the Chainsaw team is causing grief for you. If their particular application requires "equals" and "hashCode", they can implement their own wrappers as appropriate for logging events.
It appears their requirements are negatively impacting the base architecture of log4j. I'm sure there is a reasonable compromise to be made.
At this point, they have expressed their preference to have equals and hashCode with value semantics and have code that depends its presence.
At this point, I do not have compelling evidence that it is a bad thing and its best to proceed under the assumption that they knew their requirements. Adding wrappers to Chainsaw would cause an increase in total complexity by removing some complexity from the log4j core but adding more in Chainsaw.
Independently of Chainsaw's requirements, adding equals and hashCode to LoggingEvent is a good thing because equals/hashCode also make writing log4j test cases easier.
The fact that sequenceCount was introduced as a helper data field for the equals and hashCode methods was *my* choice of optimization. With hindsight, we can all agree that it was a poor optimization. Future implementations of equals and hashCode may not rely on sequenceCount (or eventId) as heavily.
Recently, I stumbled upon an interesting use case for sequenceCount. When the AsynAppender buffer is full and a event is processed, one of the waiting threads is notified that a slot became available. The order in which threads are notified is not specified by the Java language. They can be notified more or less in random order.
Consequently, events may be output out of order by AsynAppender. Sequence count can help the user to order the output.
The above should be viewed as a marginally important use case for sequenceCount, but a use case it is nonetheless.
-- 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]
