[Seaside] Logging

Boris Popov, DeepCove Labs boris at deepcovelabs.com
Thu Feb 17 19:54:44 UTC 2011


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.


-----Original Message-----
From: Dale Henrichs [mailto:dhenrich at vmware.com] 
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:)


More information about the seaside mailing list