Logging
Locked
 
|
Just curious if anyone ever considered adding pluggable or built-in logging to Seaside. Just this morning I patched WARegistry>>handleFiltered: to log unkeyed, expired and keyed requests to troubleshoot our load balancer using Toothpick’s events[1], but clearly this method is unsustainable unless I maintain my own branch of Seaside with logging. [1] http://www.metaprog.com/Toothpick/docs/loggingevent.html -Boris _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
On 02/17/2011 11:38 AM, Boris Popov, DeepCove Labs wrote:
> Just curious if anyone ever considered adding pluggable or built-in > logging to Seaside. Just this morning I patched > WARegistry>>handleFiltered: to log unkeyed, expired and keyed requests > to troubleshoot our load balancer using Toothpick’s events[1], but > clearly this method is unsustainable unless I maintain my own branch of > Seaside with logging. > > [1] http://www.metaprog.com/Toothpick/docs/loggingevent.html > > -Boris > For logging in GLASS, we've got the Object Log, which is basically an OrderedCollection of ObjectLogEntries (name, priority, timestamp, object reference) that is kept in memory...The advantage is that you can inspect the items directly rather than print the information that you think you need. For GemStone, the size of the collection doesn't matter so I log all kinds of things like mfc events, gems starting up and shutting down ... the collection is shared across all vms, so you only have to look in one place no matter how many server gems you have running ... There's also a Seaside component for accessing the Object Log. Other than having to manage the size of the collection, I think an object log is superior to the print-based form almost every time:) Dale _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Dale,
Absolutely, and in fact you could do the same with Toothpick, as its file output is optional. The key here is having these event objects announced from various places within the framework, so we could catch them and decide what to do, which at this moment involves using unmaintainable overrides. -Boris -----Original Message----- From: Dale Henrichs [mailto:[hidden email]] Sent: Thursday, February 17, 2011 2:51 PM To: Seaside - general discussion Cc: Boris Popov, DeepCove Labs Subject: Re: [Seaside] Logging On 02/17/2011 11:38 AM, Boris Popov, DeepCove Labs wrote: > Just curious if anyone ever considered adding pluggable or built-in > logging to Seaside. Just this morning I patched > WARegistry>>handleFiltered: to log unkeyed, expired and keyed requests > to troubleshoot our load balancer using Toothpick's events[1], but > clearly this method is unsustainable unless I maintain my own branch > of Seaside with logging. > > [1] http://www.metaprog.com/Toothpick/docs/loggingevent.html > > -Boris > For logging in GLASS, we've got the Object Log, which is basically an OrderedCollection of ObjectLogEntries (name, priority, timestamp, object reference) that is kept in memory...The advantage is that you can inspect the items directly rather than print the information that you think you need. For GemStone, the size of the collection doesn't matter so I log all kinds of things like mfc events, gems starting up and shutting down ... the collection is shared across all vms, so you only have to look in one place no matter how many server gems you have running ... There's also a Seaside component for accessing the Object Log. Other than having to manage the size of the collection, I think an object log is superior to the print-based form almost every time:) Dale _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Boris, have you considered decorating? or perhaps AspectS.
AOP is just asking to be used for logging concerns! _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Boris
propose a list of hooks and I hope that the seaside team will consider them because indeed this is nice to have the right hooks and avoid overrides. Stef On Feb 17, 2011, at 8:54 PM, Boris Popov, DeepCove Labs wrote: > Dale, > > Absolutely, and in fact you could do the same with Toothpick, as its > file output is optional. The key here is having these event objects > announced from various places within the framework, so we could catch > them and decide what to do, which at this moment involves using > unmaintainable overrides. > > -Boris > > -----Original Message----- > From: Dale Henrichs [mailto:[hidden email]] > Sent: Thursday, February 17, 2011 2:51 PM > To: Seaside - general discussion > Cc: Boris Popov, DeepCove Labs > Subject: Re: [Seaside] Logging > > On 02/17/2011 11:38 AM, Boris Popov, DeepCove Labs wrote: >> Just curious if anyone ever considered adding pluggable or built-in >> logging to Seaside. Just this morning I patched >> WARegistry>>handleFiltered: to log unkeyed, expired and keyed requests >> to troubleshoot our load balancer using Toothpick's events[1], but >> clearly this method is unsustainable unless I maintain my own branch >> of Seaside with logging. >> >> [1] http://www.metaprog.com/Toothpick/docs/loggingevent.html >> >> -Boris >> > > For logging in GLASS, we've got the Object Log, which is basically an > OrderedCollection of ObjectLogEntries (name, priority, timestamp, object > reference) that is kept in memory...The advantage is that you can > inspect the items directly rather than print the information that you > think you need. > > For GemStone, the size of the collection doesn't matter so I log all > kinds of things like mfc events, gems starting up and shutting down ... > the collection is shared across all vms, so you only have to look in one > place no matter how many server gems you have running ... > > There's also a Seaside component for accessing the Object Log. > > Other than having to manage the size of the collection, I think an > object log is superior to the print-based form almost every time:) > > Dale > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
2011/2/18 stephane ducasse <[hidden email]>:
> Boris > propose a list of hooks and I hope that the seaside team will consider them because indeed this is nice to have the > right hooks and avoid overrides. Absolutely. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
On 02/18/2011 09:53 PM, stephane ducasse wrote:
>> For logging in GLASS, we've got the Object Log, which is basically an >> OrderedCollection of ObjectLogEntries (name, priority, timestamp, object >> reference) that is kept in memory...The advantage is that you can >> inspect the items directly rather than print the information that you >> think you need. SimpleLog can do this too, and has a Morph UI even with search filtering and ability to filter on "sender" etc. >> For GemStone, the size of the collection doesn't matter so I log all >> kinds of things like mfc events, gems starting up and shutting down ... >> the collection is shared across all vms, so you only have to look in one >> place no matter how many server gems you have running ... And if you use the syslog emitter with SimpleLog you will get everything in one place too - the syslog. :) >> There's also a Seaside component for accessing the Object Log. >> >> Other than having to manage the size of the collection, I think an >> object log is superior to the print-based form almost every time:) >> >> Dale Well, I kinda like logs being "stupid" sometimes. They are around even if the db isn't etc. regards, Göran _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |