[PEAK] Logging to Email

[Phillip J. Eby]

At 08:31 AM 1/2/04 +0000, Bill Trenker wrote:
>I'm one of those programmers who learns best by example so I'm very 
>grateful for "IntoToPeak".  The recent discussion on logging twigged me to 
>read Lesson 5 in the "Intro".  Pondering the logtee example got me 
>wondering if there is a way of sending log messages to an email address?
>
>If the "really worried boss" in the example is away from the office, it 
>might make sense for him/her to be notified of critical log messages by email.

Just FYI, chapter 5 doesn't reflect the actual state of PEAK.  R.D. wrote 
it based on an impression that certain features were available that 
actually aren't.  ('logtee' and 'syslog'.)

Anyway, right now you could implement such a thing by subclassing 
AbstractLogger and implementing the 'publish()' method as sending to 
email.  You would then register an instance of your subclass as a property 
in the 'peak.logs' namespace.


(And now for something completely different...)

In future (i.e. by the a3 release), you'd do this instead by implementing a 
plugin implementing ILogHandler (which doesn't exist yet) and registering 
it as a listener for the appropriate category or categories.

I recently added support for plugins to the peak.config architecture, but 
nothing actually uses them yet.  Partly, this is waiting on the ZConfig 
"schema service" and ZConfig file URL support, because it'll be easier to 
create and register plugins of most kinds using ZConfig files.  E.g.:

[ZConfig.schemas]
loggers = naming.LinkRef('pkgfile:peak.running/Loggers.xml')

[peak.logging-plugins]
my-plugins = naming.LinkRef('zconfig.loggers:/foo/bar')


The idea here is that when the ILoggingService loads plugins from the 
'peak.logging-plugins' namespace, it will then load the ZConfig file 
/foo/bar using a schema found in 'Loggers.xml' in the 'peak.running' 
package.  Those plugins can then have assembly events that will register 
them as listeners for the appropriate events.

These generic plugin and ZConfig schema support mechanism should be usable 
for lots of other things, including perhaps some of the projects that 
Alexander and others have mentioned on this list.

Interestingly, the new plugin mechanism can be compared to Eclipse's 
concept of "Extension points" and "Extensions".  You could even implement 
an automatic plugin loading system by doing something like:

[Import on Demand]
glob = "glob"

[Load settings from]
files = glob.glob("/someProg/plugins/*/plugins.ini")

Each subdirectory of 'plugins' would have a 'plugins.ini' that would 
register plugins for the various "extension points" that might need to be 
hooked.  Some of those plugins might in turn be loaded-on-demand from 
ZConfig files, etc.