I'm sorry, that was a bit confusing.
Let me explain:
Chainsaw supports loading events from XML files - either conforming to log4j.dtd or jdk1.4 util.logging's logger.dtd.
Chainsaw also supports saving a tab's events to XML - conforming to log4j.dtd.
When Chainsaw saves events to an XML file, and the user then re-loads the file into Chainsaw, we want to have the resulting panel display exactly the same as when the panel's events were saved.
Currently, in order to preserve the ID field in the log panel associated with the event (and prevent duplicates), I append a property to each event called 'log4jid' with the ID value for the current row, as you see in Chainsaw's log panel.
JDK util.logging's XML format provides this ID and the utilloggingdecoder (supported by a number of receivers) converts the id value to the log4jid property prior to posting the event.
Each logging event's ID is also added to a hashset, and a 'contains' call is made on the hashset to determine whether or not the event identified by the ID field is already in the buffermodel.
With regard to LoggingEvent's equals method:
* we should probably check for object identity (if x == this return true) early on in the method
* we also need to add equals methods to locationinfo and throwableinfo
Unless we declare that two events to be equal even if their location info or throwableinfo are different. I mean what is the likelihood of two events to differ in their locationinfo or throwableinfo but match in all other fields?
Of course, adding equals to these two classes will be safer. I am probably arguing in favor of a potential bug...
ThrowableInformation seemed to be somewhat of an issue because we need to decide whether or not the throwable should be compared to the string representation, or if they should only be compared against eachother.
I'd say against the string representation because speed should not be an issue for two reasons.
1) It is the string representation which we output anyway. (Thus, the cost of conversion to string[] will be eventually paid anyhow).
2) More importantly, logging events containing exceptions are rare, so speed is not an issue in the first place!
Actually, I think
public ThrowableInformation(Throwable throwable) {
this.throwable = throwable;
}should be changed to:
public ThrowableInformation(Throwable throwable) {
rep = getThrowableStrRep(throwable);
}Scott
-- Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
