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 21:11:02 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 as an embedded server vs Logging as a standalone server ==
  
+ We should not distribute default logging configuration files - for example, log4j.properties
- in the jar distribution of the server. There's a high chance it will conflict with applications
which use the same logging system and list the server as a dependency. This simply means that
the maven jar:jar goal should not include a log4j.properties, it can be renamed to apacheds-log4j.properties
instead.
  
+ When starting the server in standalone mode, i.e. as a jar, a System property should be
applied "log4j.configuration" to indicate that apacheds-log4j.properties (see http://logging.apache.org/log4j/docs/manual.html#defaultInit).
I have yet to test this with nlog4j will update this later, having done so. A wrapper script,
server-standalone.sh/server-standalone.bat could make this easy.
  
  == 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. 
+ 
+ I'm not sure what will happen if two implementations of slf4j are placed on the classpath.
Something to discover, I suppose.
  
  
  == 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.. 
+ For example, an admin. might select to run the authentication protocol at DEBUG, the b-tree
component at FATAL, and the search component at INFO. This ability can be especially useful
when dealing with integration projects, working on performance issues, etc.. 
+ 
+ It would probably become more viable to associate configurable logging levels with 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.
  

Mime
View raw message