Page 1 of 1

Live Monitor

Posted: 04.04.2010, 17:46
by bravecobra
Hi,

I'm trying to implement a live monitor for ZeosLib. Instead of writing to a file, like the current monitor does, I want to broadcast the message, for another application to pick up. A great example is the dbmon application that DevArt uses. Even better would be to implement their interface (we would have to check licensing here), however the TZLoggingEvent doesn't return a reference to the component that triggered the log entry, only some text being the Message property and some other values like the protocol, category and timestamp.

I'd propose something like this:

Code: Select all

TZLoggingEvent = class (TObject)
  ...
  public
    constructor Create(Category: TZLoggingCategory; Protocol: string;
      Msg: string; ErrorCode: Integer; Error: string; Component:TComponent);
  ...
Once we have a component reference in TZLoggingEvent, we can then query that component on its properties to determine valuable information that otherwise would get lost.
For example, sometimes you see SQL passing by and you wonder where in the application it gets executed. What's the name of the component that executes this query? What are its parameters values? etc..

I know that changing the constructor of TZLoggingEvent, would mean changing every call to it everywhere in the code, but that can parsed easily (passing nil by default is not an option, as it would result in the same situation as before).

Remarks? Should I prepare a patch?

Posted: 05.04.2010, 17:59
by bravecobra
To give you an idea of what it can do, here's a picture of this live logging. Messages are being added when they occur.

Unfortunately I can't get to the values of the params and the names of the components that triggered the execution, since I don't have those in TZLoggingEvent.

Posted: 13.04.2010, 22:27
by mdaems
Brave,

We had requests like this before. There's even a patch from gto. You propose to add a component parameter to the logging event. My most important question is, what could be the possible component classes for this parameter? If it should be a zeoslib component you're certainly running into trouble when using zeolib with the dbc layer only.
Also, I believe the main problem always was there are events which are logged on places where a component wasn't known yet.

Have you tried to make the patch? Please show us. If you were able to implement this in zeoslib 7 without breaking compatibility with existing programs too much, I'll really consider adding the new possibilities to zeoslib 7.

Mark

Posted: 16.04.2010, 02:58
by bravecobra
I'll see whether I can cook up something that could work. In my opinion a TComponent argument could suffice. When unknown, just pass nil. Sometimes you want to log something that's not even component related.
Not breaking existing programs can be done by using an overloaded one.