directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Directory Wiki] Update of "LoggingPlan" by CKoppelt
Date Fri, 16 Feb 2007 00:18:50 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 CKoppelt:

- Logging in Directory Server is handled by SLF4J - .
+ deleted
- Find below a roadmap for developing logging in the server.
- == Logging Location ==
- Default behaviour should see logging saved to a /logs directory as apacheds.log .
- 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 ==
- We should not distribute default logging configuration files - for example,
- 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. One way to ensure it
is not distributed would be to ensure that maven jar:jar goal renames to This would mean that, during development, IDEs will be able to
use logging effectively but that, after being placed on a maven repo., parent applications
would not be worried by it.
- When starting the server in standalone mode, i.e. as a jar, a System property should be
applied "log4j.configuration" to indicate that (see
I have yet to test this with nlog4j will update this later, having done so. 
- A wrapper script, could make this easy. We can
also use this to set default min/max heap sizes on the JVM.
- == 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. 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.
- This needs to be worked at later on, when a server administrator console appears - not before.
- == Federated Logging, Logging across a cluster ==
- We can handle this when apacheds gets close to running in a cluster.

View raw message