$Id: logging,v 1.4 2008-04-01 20:23:48 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.
Another way to set the logging level, useful mostly when running test
scripts from the command-line, is by setting the KRloglevel
environment variable. This can also be set from the web-server
configuration (along with KRuser, KRpw, etc.) to indicate a default
logging-level.
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.