XmlTraceListener.TraceData bug?

Topics: Logging Application Block
Feb 12, 2007 at 4:53 PM
I posted this in a different subject last week. Got no reply. Am taking a different tack now. I find that when using XmlTraceListener, all my traces will have the same timestamp, callstack, etc as were cached upon the construction of its LogSource. Here's why: When a LogSource is constructed, it instantiates its "manager" member:

public LogSource(string name, List<TraceListener> traceListeners, SourceLevels level)
{
//...
this.manager = new TraceEventCache();
//...
}
When the LogSource logs, it calls
XmlTraceListener.TraceData(this.manager ...);

This "manager" is read by XmlWriterTraceListener to add the appropriate Timestamp to the log entry. But it never gets changed in successive logs. You end up with all logs having the same timestamp, callstack, etc.

Is this a known issue? Or am I missing something?
Riley
Feb 12, 2007 at 7:55 PM
Hi Riley -

Sorry we didn't respond to this before. This is a bug, and we'll fix it. For those playing at home, the issue is that we reuse the TraceEventCache instance across calls. The .NET TraceSource class gets around this by calling Clear() on the TraceEventCache, but since this method is internal we'll probably need to change the code to recreate the TraceEventCache each time.

Tom
Feb 12, 2007 at 8:09 PM
Thanks Tom,
Yes, the way we are working around this is to extend XmlTraceListener, and override the TraceData call to pass a new TraceEventCache to the base class method. This is not really spot on yet, because timestamp and callstack are not exactly what they would be if they were set at the time the LogEntry was originally created, as would be expected by our users.
Riley