[experimental/in-progress] Framework agnostic pure object logging for Zinc
Hi, Since years, Zinc has been using its own Announcements-based logging mechanism for client and server logging. The payload of the Announcements used was still essentially text based though. In some discussions months ago with Norbert Hartl in the context of his work on SystemLogger, the concept of pure object logging as an alternative to text based logging became an interesting alternative for me. In an internal project that I did earlier this year I tried out this concept for myself and was quite happy with the result. Doru Girba had indicated several times to me that he was also interested in thinking about logging, so when he started talking about Beacon, I decided to write down my ideas a bit in a quick draft: https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md And to make this even clearer, I had to change Zinc logging to work along these principles. The current #bleedingEdge experimental/in-progress version of Zinc now contains a first working version of 'framework agnostic pure object logging'. The conversion is not yet finished - there is still much to learn here - but it already looks quite nice I think. Monitoring logging output can be done by opening an Announcement Spy. ZnNewLogEvent open. Next you run some code (start a server, do one request, stop the server). (ZnServer defaultOn: 1701) route: #server1; start. ZnClient new clientId: #client1; beOneShot; get: 'http://localhost:1701/random'. ZnServer stopDefault. Which give the following output (using the standard string representation). However, each line is a rich object containing tons of information. Here is the highlighted line in the Explorer. As you can see, all information from during the client and the server's execution is preserved, ready to be used for logging and/or debugging, right now or later on. Nowhere in the main ZnClient or ZnServer logging code is there simple string or text logging, everything being logged by announcing a log event object. I hope that this plays well with both SystemLogger, Beacon and maybe other logging frameworks out there. When I bring this approach more and more in production use, it will most probably evolve further. In the meantime, have a look: I would love feedback. Sven
Hi sven Objects are the way to go. Will this compatible be with SystemLogger? I mean could not you use SystemLogger? Because I do not see them why I spend my time to build infrastructure. Stef
Hi,
Since years, Zinc has been using its own Announcements-based logging mechanism for client and server logging. The payload of the Announcements used was still essentially text based though.
In some discussions months ago with Norbert Hartl in the context of his work on SystemLogger, the concept of pure object logging as an alternative to text based logging became an interesting alternative for me. In an internal project that I did earlier this year I tried out this concept for myself and was quite happy with the result.
Doru Girba had indicated several times to me that he was also interested in thinking about logging, so when he started talking about Beacon, I decided to write down my ideas a bit in a quick draft:
https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md
And to make this even clearer, I had to change Zinc logging to work along these principles. The current #bleedingEdge experimental/in-progress version of Zinc now contains a first working version of 'framework agnostic pure object logging'. The conversion is not yet finished - there is still much to learn here - but it already looks quite nice I think.
Monitoring logging output can be done by opening an Announcement Spy.
ZnNewLogEvent open.
Next you run some code (start a server, do one request, stop the server).
(ZnServer defaultOn: 1701) route: #server1; start.
ZnClient new clientId: #client1; beOneShot; get: 'http://localhost:1701/random' <http://localhost:1701/random%27>.
ZnServer stopDefault.
Which give the following output (using the standard string representation).
However, each line is a rich object containing tons of information. Here is the highlighted line in the Explorer.
As you can see, all information from during the client and the server's execution is preserved, ready to be used for logging and/or debugging, right now or later on.
Nowhere in the main ZnClient or ZnServer logging code is there simple string or text logging, everything being logged by announcing a log event object.
I hope that this plays well with both SystemLogger, Beacon and maybe other logging frameworks out there.
When I bring this approach more and more in production use, it will most probably evolve further. In the meantime, have a look: I would love feedback.
Sven
Hi Stef, The way I see it is that the Zinc Log Announcements will work quite well with Beacon, but less smooth with SystemLogger because you will need another layer of indirection. This is because SystemLogger is not relying directly on Announcements. I think the model of Beacon is simpler. Please note that I am not looking to start a war :). I am sure there are things I did not consider in Beacon, and this is why it would be great to work together to build a common engine that we can integrate in the image. Cheers, Doru On Mon, Jun 16, 2014 at 8:25 AM, stepharo <stepharo@free.fr> wrote:
Hi sven
Objects are the way to go. Will this compatible be with SystemLogger? I mean could not you use SystemLogger? Because I do not see them why I spend my time to build infrastructure.
Stef
Hi,
Since years, Zinc has been using its own Announcements-based logging mechanism for client and server logging. The payload of the Announcements used was still essentially text based though.
In some discussions months ago with Norbert Hartl in the context of his work on SystemLogger, the concept of pure object logging as an alternative to text based logging became an interesting alternative for me. In an internal project that I did earlier this year I tried out this concept for myself and was quite happy with the result.
Doru Girba had indicated several times to me that he was also interested in thinking about logging, so when he started talking about Beacon, I decided to write down my ideas a bit in a quick draft:
https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md
And to make this even clearer, I had to change Zinc logging to work along these principles. The current #bleedingEdge experimental/in-progress version of Zinc now contains a first working version of 'framework agnostic pure object logging'. The conversion is not yet finished - there is still much to learn here - but it already looks quite nice I think.
Monitoring logging output can be done by opening an Announcement Spy.
ZnNewLogEvent open.
Next you run some code (start a server, do one request, stop the server).
(ZnServer defaultOn: 1701) route: #server1; start.
ZnClient new clientId: #client1; beOneShot; get: 'http://localhost:1701/random'.
ZnServer stopDefault.
Which give the following output (using the standard string representation).
However, each line is a rich object containing tons of information. Here is the highlighted line in the Explorer.
As you can see, all information from during the client and the server's execution is preserved, ready to be used for logging and/or debugging, right now or later on.
Nowhere in the main ZnClient or ZnServer logging code is there simple string or text logging, everything being logged by announcing a log event object.
I hope that this plays well with both SystemLogger, Beacon and maybe other logging frameworks out there.
When I bring this approach more and more in production use, it will most probably evolve further. In the meantime, have a look: I would love feedback.
Sven
-- www.tudorgirba.com "Every thing has its own flow"
On 16 Jun 2014, at 08:25, stepharo <stepharo@free.fr> wrote:
Hi sven
Objects are the way to go.
Yes !
Will this compatible be with SystemLogger? I mean could not you use SystemLogger?
I hope that SystemLogger can work with a subsystem that generates a stream of log objects, without requiring them to be subclasses of something. If so, then it will be compatible (just connect the announcer to where you want to sent the objects to). If not, then I don't understand how SystemLogger can be a pure object log. I said this before (and I miss this in the SystemLogger documentation, and even in the Beacon description): show real object based logging from the beginning, not degenerate string logging. In the case of SystemLogger, the class BasicLog already contains a message, why ? The API is also still mainly expressed with strings. (BTW, there should not be a messageText in exception, for example, being an instance of ZeroDivide or KeyNotFound with a key says it all). And like in the basic BeaconSignal, you predefine a timeStamp, why ? Is it really needed, or not ? In my other projects I don't use DateAndTime but ZTimestamp, things like that should not be forced on user. A timestamp even with high precision is not necessarily unique, that is why I added a secondary id.
Because I do not see them why I spend my time to build infrastructure.
Sure, I need/want a nice backend with lots of functionality (like what Norbert was experimenting with). Also, for casual usage, some classes to inherit from are useful. Maybe a system level API as well. Second, we will probably need conventions, maybe expressed as traits of useful attributes for log objects so that we can write general analysis tools.
Stef
Hi,
Since years, Zinc has been using its own Announcements-based logging mechanism for client and server logging. The payload of the Announcements used was still essentially text based though.
In some discussions months ago with Norbert Hartl in the context of his work on SystemLogger, the concept of pure object logging as an alternative to text based logging became an interesting alternative for me. In an internal project that I did earlier this year I tried out this concept for myself and was quite happy with the result.
Doru Girba had indicated several times to me that he was also interested in thinking about logging, so when he started talking about Beacon, I decided to write down my ideas a bit in a quick draft:
https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md
And to make this even clearer, I had to change Zinc logging to work along these principles. The current #bleedingEdge experimental/in-progress version of Zinc now contains a first working version of 'framework agnostic pure object logging'. The conversion is not yet finished - there is still much to learn here - but it already looks quite nice I think.
Monitoring logging output can be done by opening an Announcement Spy.
ZnNewLogEvent open.
Next you run some code (start a server, do one request, stop the server).
(ZnServer defaultOn: 1701) route: #server1; start.
ZnClient new clientId: #client1; beOneShot; get: 'http://localhost:1701/random'.
ZnServer stopDefault.
Which give the following output (using the standard string representation).
<Mail Attachment.png>
However, each line is a rich object containing tons of information. Here is the highlighted line in the Explorer.
<Mail Attachment.png>
As you can see, all information from during the client and the server's execution is preserved, ready to be used for logging and/or debugging, right now or later on.
Nowhere in the main ZnClient or ZnServer logging code is there simple string or text logging, everything being logged by announcing a log event object.
I hope that this plays well with both SystemLogger, Beacon and maybe other logging frameworks out there.
When I bring this approach more and more in production use, it will most probably evolve further. In the meantime, have a look: I would love feedback.
Sven
Am 16.06.2014 um 09:15 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 16 Jun 2014, at 08:25, stepharo <stepharo@free.fr> wrote:
Hi sven
Objects are the way to go.
Yes !
Will this compatible be with SystemLogger? I mean could not you use SystemLogger?
I hope that SystemLogger can work with a subsystem that generates a stream of log objects, without requiring them to be subclasses of something. If so, then it will be compatible (just connect the announcer to where you want to sent the objects to). If not, then I don't understand how SystemLogger can be a pure object log.
I said this before (and I miss this in the SystemLogger documentation, and even in the Beacon description): show real object based logging from the beginning, not degenerate string logging.
In the case of SystemLogger, the class BasicLog already contains a message, why ? The API is also still mainly expressed with strings. (BTW, there should not be a messageText in exception, for example, being an instance of ZeroDivide or KeyNotFound with a key says it all).
This is somethings that bugged me for a long time. The message instVar in BasicLog has probably a misleading name. The message is suppsoed to contain any object not just a string. BasicLog and Log are not supposed to be subclassed if you havenât special needs. BasicLog has two instVars: a timestamp and a message object. It acts as a decorator for any object you like to log. Therefor we have Object>>#asLog ^ self class newLog message: self Object class>>#newLog ^ self logClass new Object class>>#logClass "Hook supporting the redefinition by object of their associated log. When using myObject asLog emit, the logClass will be used and myObject will be passed as message argument." ^ Log If you need another decorator for your log objects then you override #logClass on the class side of your business object. This is exactly so you do not have to derive your objects from any class in SystemLogger. The BasicLog resembles the most basic thing. To me a log entry has always a timestamp when the event occurred. And there is a message instVar for keeping any object. The Log class derives from BasicLog and resembles a Log class that is used in other frameworks/operating systems. How the Log is converted to is defined in the Loggers itself at the best possible time before they leave the image. Norbert
And like in the basic BeaconSignal, you predefine a timeStamp, why ? Is it really needed, or not ? In my other projects I don't use DateAndTime but ZTimestamp, things like that should not be forced on user. A timestamp even with high precision is not necessarily unique, that is why I added a secondary id.
Because I do not see them why I spend my time to build infrastructure.
Sure, I need/want a nice backend with lots of functionality (like what Norbert was experimenting with). Also, for casual usage, some classes to inherit from are useful. Maybe a system level API as well.
Second, we will probably need conventions, maybe expressed as traits of useful attributes for log objects so that we can write general analysis tools.
Stef
Hi,
Since years, Zinc has been using its own Announcements-based logging mechanism for client and server logging. The payload of the Announcements used was still essentially text based though.
In some discussions months ago with Norbert Hartl in the context of his work on SystemLogger, the concept of pure object logging as an alternative to text based logging became an interesting alternative for me. In an internal project that I did earlier this year I tried out this concept for myself and was quite happy with the result.
Doru Girba had indicated several times to me that he was also interested in thinking about logging, so when he started talking about Beacon, I decided to write down my ideas a bit in a quick draft:
https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md
And to make this even clearer, I had to change Zinc logging to work along these principles. The current #bleedingEdge experimental/in-progress version of Zinc now contains a first working version of 'framework agnostic pure object logging'. The conversion is not yet finished - there is still much to learn here - but it already looks quite nice I think.
Monitoring logging output can be done by opening an Announcement Spy.
ZnNewLogEvent open.
Next you run some code (start a server, do one request, stop the server).
(ZnServer defaultOn: 1701) route: #server1; start.
ZnClient new clientId: #client1; beOneShot; get: 'http://localhost:1701/random'.
ZnServer stopDefault.
Which give the following output (using the standard string representation).
<Mail Attachment.png>
However, each line is a rich object containing tons of information. Here is the highlighted line in the Explorer.
<Mail Attachment.png>
As you can see, all information from during the client and the server's execution is preserved, ready to be used for logging and/or debugging, right now or later on.
Nowhere in the main ZnClient or ZnServer logging code is there simple string or text logging, everything being logged by announcing a log event object.
I hope that this plays well with both SystemLogger, Beacon and maybe other logging frameworks out there.
When I bring this approach more and more in production use, it will most probably evolve further. In the meantime, have a look: I would love feedback.
Sven
participants (5)
-
Ben Coman -
Norbert Hartl -
stepharo -
Sven Van Caekenberghe -
Tudor Girba