Logging should be as easy as writing a comment! Writing a log statement should not require the developer to interrogate variables and objects and manually convert them into strings. The state checking and manual conversion code tends to get duplicated.

Logahawk uses Formatters to avoid thi unnecessary tedium and make a log statement a one-line call.

For example, log4j might require this:

if ( logger.isErrorEnabled() )
{
    String msg = String.format("Failed to insert Employee %s in Company %s",
            emp.getId(), company.getId());
    logger.error( msg );
}
      

Logahawk would expect this:

logger.error("Failed to insert Employee %s in Company %s", emp.getId(), company.getId());
      

(Filtering is handled automatically by SeverityFilterLogger and formatting handled automatically by FormatterSigFormatter.

Or with custom Formatters:

logger.error("Failed to insert", emp, company);
      

Logs should provided lots of information and be easy for developers andoperators to read. Logs can be a system's heartbeat monitor, an application's autobiography, and a program's status report all in one. But far to often logs are terse and limited because writing good log statements is often too awkward to let developers naturally achieve this value.

Logahawk's Formatters allow a wealth of information to be written to the log without burdening the developer with these details. A general purpose logger will only provide general purpose information, and can be analyzed only be general purpose tools. Every serious application either works within a domains or creates a new domain, and that domain has its own vocabulary and lingo. The Formatters allow developers to create domain specific loggers.

Logahawk is designed as a wrapper or an adapter to your existing logging infrastructure. Logahawk's design is agnostic to any particular logging framework. How you decide to integrate Logahawk with your application is completely up to you. See Integration for details.

Every significant construct in Logahawk is defined by an interface. Developers have the freedom to replace anything and everything. Many logging frameworks make it difficult to extend or outright replace their core classes, either using static classes or abstract base classes instead of interfaces.

Hand-in-hand with the difficulty of extending many logging framework's core classes, many logging frameworks provide (and some even require) a single configuration mechanism, usually configuration files (or databases or whatever). Very few, if any, allow configuring logs at compile-time or dynamically at run-time. Logahawk leaves configuration up to the developer and the underlying logging framework, allowing the developer to configure logging exactly as they want. This can allow for such ad-hoc flexibility, but depends on your underlying logging framework. (Logahawk was actually designed for a system that needs the ability to dynamic create new log files at runtime, and where a user-editable configuration file and user-readable logs are a security risk).