directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Directory Wiki] Update of "LoggingPlan" by nickfaiz
Date Wed, 27 Jul 2005 20:52:35 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Directory Wiki" for change notification.

The following page has been changed by nickfaiz:
http://wiki.apache.org/directory/LoggingPlan

------------------------------------------------------------------------------
  Logging in Directory Server is handled by SLF4J - http://slf4j.org .
  
- Find below a plan for developing logging in the server.
+ Find below a roadmap for developing logging in the server.
  
  == Logging Location ==
  
@@ -10, +10 @@

  
  The location of this directory should be configurable but it should be tied to a server_home
variable. The server_home directory can be the typical application directory for storing configuration
files, etc.. This might be the same thing as the server working directory.
  
+ == Logging as an embedded server vs Logging as a standalone server ==
+ 
+ 
+ 
  == Choice of Logging Framework ==
  
  SLF4J is ideal because it should allow any logging framework to be swapped in - this is
achieved by ensuring that the correct jar is on the classpath (no dynamic classloading takes,
it keeps things simple). Thus, we do not have to do much work here - we simply have to tell
people how to locate the default slf4j implementation - nlog4j.jar - and replace it with their
own jar. 
  
- == Logging as an embedded server vs Logging as a standalone server ==
  
  == Component specific logging ==
  
+ One idea to consider, eventually, is runtime, admin. configurable logging. Following this
idea, server admin.s should be able to set logging levels for components or families of components
at runtime. 
+ 
+ For example, an admin.s might select to run the authentication protocol at DEBUG, the b-tree
component at FATAL, and the search component at INFO. It would probably become more viable
to build families of components here, as authentication might apply to SSL, plain, etc., search
might apply to processing ldap search responses, referrals, etc.. 
+ 
+ This way auditing (which some organisations require) should also be achieveable by pushing
everything to an info. level.
+ 
+ This needs to be worked at later on, when a server administrator console appears - not before.
+ 

Mime
View raw message