RE: logging enhancements, take 2

[Gary Williams <Gary.Williams@sas.com>]

OK, consider me off and running on this.  Someone asked that
thread number be put on log lines.  In the slapd logging, I
would also like to see the connection number added.  The output
should look like:

date                   thread     cnxn     output
20001009:14:20:24.392 [t:_thrd_] [c:_cnx_] Debug output from slapd code.

This information doesn't apply to client logging (usually).  Should
the slapd logging macro require these, and the logging
function put them in the output string, or just as a convention,
request that calls to the logging routines include them?

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Monday, October 09, 2000 1:56 PM
> To: Gary Williams
> Cc: 'openldap-devel@openldap.org'
> Subject: Re: logging enhancements, take 2
> 
> 
> At 01:02 PM 10/9/00 -0400, Gary Williams wrote:
> >Here's what I have for libldap:
> >
> >The following is added to print.c.  Similar changes would be 
> made in modules
> >for the other libraries (liblber, libavl, etc.)  A static 
> variable holding the
> >address of an external logging routine, and functions that 
> can set and get the
> >address.  The debugging macro would then check the external 
> function and use it
> >if it's been set, otherwise use the existing logging routine.
> 
> I suggest a slight twist...
> 
> It would be nice if could always use the macro:
>         LDAP_LOG( subsys, level, fmt, ...)  /* preferred */
> or
>         LDAP_LOG(( subsys, level, fmt, ...))
> 
> no matter which subsys we were in... but than inside each
> subsystem requiring independent logging (-lldap -llber),
> this would use an internal such as ber_int_logger() instead of
> the full lutil logger.  OpenLDAP applications would call call
> lutil_log_initialize() to (amongst other things) install the
> full logger, lutil_int_logger().
> 
> It's best to use a function to do the switching (using an
> internal hook), then to expose the hook, hence, I suggest:
>         #define LDAP_LOG ber_pvt_logger  /* preferred */
> or
>         #define LDAP_LOG(x) ( ber_pvt_logger x )
> 
> and let ber_pvt_logger() determine whether or not to use
> ber_int_logger() or lutil_int_logger() (as installed via the hook).
> 
> As far as the hook...
> >static void (*ldap_logProc) LDAP_P(( char *subsys, int 
> level, char *fmt, ... ));
> 
> That's reasonable prototype, but the hook needs to be -llber and
> should be named per conventions, i.e:
>   static void (*ber_int_log_proc)( const char *subsys, int level,
>         const char *fmt, ... )
> 
> And should be set using:
>   ber_set_option( NULL, LBER_OPT_LOG_PROC, (void*) lutil_int_logger )
> 
> from lutil_log_initialize()
> 
> [contrary to what I might have said previously] I would suggest that
> the default logger (lber_int_logger) use a global log level (as this
> is simpler to implement) which could be accessed via either
> LBER_OPT_DEBUG or LDAP_OPT_DEBUG (LDAP_OPT_DEBUG would set 
> LBER_OPT_DEBUG).
> This means that a non-OpenLDAP application setting TRACE gets TRACE
> across all subsystems (-lldap and -llber).  I don't have much problem
> with this.
> 
> >If this is acceptable, I'll proceed putting it in all the 
> libraries and updating the
> >configuration routines and command lines to accept logging 
> configuration. 
> 
> For command line, reuse -d.
>