$Id: logging,v 1.3 2008-03-26 16:33:18 mike Exp $

Logging behaviour in Keystone Resolver is specified by a combination
of logging levels, documented in the Keystone::Resolver::LogLevel
manual.  The simplest way to generate logging of a resolution is to
set the "loglevel" option, which can be achieved by including an
"opt_loglevel" component in the OpenURL to be resolved.  For example,
including:
	opt_loglevel=dblookup,sql
will cause logging to be emitted describing both application-level use
of the database ("dblookup", which notes calls such as
genre_by_mformat() and services_by_type()), and the low-level SQL
statements issued in order to fulfil those requests.

In additional to Keystone Resolver's own logging, Perl's DBI libarary
(the layer that uses the underlying database software) can generate
low-level logging of its own.  This is most simply achieved by
providing the opt_dbi_trace query parameter with a value that is a
small integer.

Where does logging appear?  It is written to the standard error
stream, which should mean that it appears in an Apache log-file when
running under Apache.  Unfortunately, under Apache 2.x, it resolutely
appears in the global error.log rather than in the
application-specific keystone-resolver-error.log, where it appears
under Apache 1.x.  I've not been able to find a way to fix this wart,
not even by aliasing CORE::warn() to Apache2::ServerRec::warn().  See
the comments function on the function apache_non_moronic_logging() in
Keystone::Resolver::Utils for details.  The upshot is that you have to
watch _both_ logs.

