Re: new logging code in branch

[Justin Mason <jm...@jmason.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


is this for 3.1.0?   if so, I'd prefer to just bodge it into the
trunk right now, so it gets enough eyes on it...  I'm not sure
if I'm going to get around to checking out that branch.

- --j.

Daniel Quinlan writes:
> (not the 3.0 branch ;-)
> 
> I've been having issues with the logging code, so I rewrote it.  It's
> now a module.  The Logger.pm module is not a true object to avoid
> passing around a silly log object, but the log method modules are all
> objects, so it is kinda clean.
> 
> I investigated, much to the detriment of my time, making this a plugin
> and the main issue there is that Exporter completely refuses to work
> (allowing dbg() and friends to be exported) whenever the necessary data
> from Mail::SpamAssassin is included, some sort of circular reference
> problem.  Now, however, I'm convinced that plugins are not the right way
> to go so logging via this API can be done as early as possible.
> 
> It also fixes the fact that die() messages were completely unlogged
> before, although I'm not entirely happy with how this is done.
> 
> How does it work?
> 
>  - use Mail::SpamAssassin::Logger
>  - all code gets to dbg() and info()
>  - front-ends can set up a handlers warn() and a die() callback
>  - stderr method is always on by default
>  - syslog and file methods can be added
>  - methods can be removed
>  - dbg_check() and info_check() are now in would_log(), instead of
>    using the '+' prefix to mean "was it specifically enabled for
>    debugging", would_log just returns 2 instead of 1 if a facility
>    was specifically enabled
> 
> Also, I rewrote all of the logmsg() calls in spamd to use the proper
> dbg(), info(), warn(), and die() calls directly.
> 
> I'm trying a new experiment, a short-term branch in SVN, to allow others
> to poke at it (Michael's idea).
> 
>   https://svn.apache.org/repos/asf/spamassassin/branches/logger
> 
> It almost works and is fairly close to where I want it to be, but some
> things still need to be fixed:
> 
>   - a few broken t tests
>   - edge cases (first few log messages, etc.)
>   - finalizing the APIs and documenting them
> 
> The __WARN__ and __DIE__ stuff is a bit weird.  die() is weird in that
> you have to avoid catching eval() deaths due to how the stupid perl
> interpreter sends die() from trapped evals to an external __DIE__
> callback.  I have some vague worries such as third-party code mucking
> with __WARN__ too.  die() can also send two messages: the usual one to
> STDERR and I'm not sure how to override that and the one we actually log
> (possibly to stderr as well).  I'd rather have that problem than the
> reverse of no logging for die.
> 
> I suppose log_message() could explicitly not send die log messages to
> stderr (create a new log level for "die", map it to 'err' in the method
> objects, and don't send those to stderr).
> 
> Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFCZuy1MJF5cimLx9ARAhP5AJ0XeU4gOkiVhCjG8cCAU4ZaTYBKZQCgklQm
MVZ/esMkc6Q7DPDOOG9VPJs=
=C6A0
-----END PGP SIGNATURE-----

Re: new logging code in branch

[Daniel Quinlan <qu...@pathname.com>]

Justin Mason <jm...@jmason.org> writes:

> is this for 3.1.0?

Yes.  The debug code already changed from 3.0 so it'd be MUCH better to
change it once from the perspective of outside users rather than twice.

> if so, I'd prefer to just bodge it into the trunk right now, so it
> gets enough eyes on it...  I'm not sure if I'm going to get around to
> checking out that branch.

Hmm... okay, done.  A few tests break at the moment, I'll try to get
those all fixed tonight.  Michael said he'd take a look too.

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/