Proposals:Logging: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
No edit summary
Line 69: Line 69:
* Replace Error / Warning Macros
* Replace Error / Warning Macros
* Begin using in existing and new classes
* Begin using in existing and new classes
= Option of Writing our own =
This option involves to develop a set of new ITK classes intended for providing the logging functionalities.
=== Pros ===
* Complete control over the code
* Only implements what we need
* Focus on performance on the context of ITK uses
=== Cons ===
* Potentially reinventing the wheeel
=== Potential Implementations ===
==== Adapt IGSTK classes ===
Sohan Rajan from the ISIS Center at Georgetown University has already develop a starting framework for providing logging capabilities. We could take these classes and extend them as appropriate in order to fulfill the needs of the ITK community.

Revision as of 20:57, 26 March 2005

Requirements

Current Status

Logging capabilities are currently available in ITK through very limited mechanism that involve the use of the following element

  • itkWarningMacro
  • itkExceptionMacro
  • TextOutput

Advantages

  • It is already there  :-)
  • It is fully implemented using ITK classes. We have complete control over the code
  • It is compact and easy to maintain

Drawacks

The drawacks of the current functionalities are

  • The TextOutput is by default sent to an OutputWindow that lacks an event-loop. It is then usually the case that users/developers dont have a chance to look at the error messages because they are scrolled rapidly and there is no way to get them back.
  • Messages are not send to files. Currently this could only be done by each developer creating a class deriving from the OutputWindow and redirecting the messages to a file.
  • Level of granularity. The current approach only have "ERROR" messages that are thrown through exceptions and warning messages.

Option of using Log4cxx

log4cxx is a logging package modeled on log4j, a popular logging package for Java.


Usage

Each class in ITK would have a static class variable pointing to a logger. The logger's are named, with the usual naming convention being org.itk.Code.Common.Object, essentially a namespace / Java package hybrid. Names define a hierarchy, so org.itk.Code is the parent of org.itk.Code.Common, org.itk.Code.BasicFilters, etc... There are different levels of log messages, debug, info, warn, error, fatal and log. The developer decides when and where to put a logging message, and it's severity.

At runtime, the application defines the threshold of messages to be logged, i.e. debug and higher, or info and higher. A logger inherits it's threshold from it's parent, if not specified. Thus it is easy to shut off logging messages from org.itk.Code all at once.

In addition to thresholds, different output options are available called Appenders. For instance:

  • Console: essentially std::cout
  • File: Log to a file
  • SMTP: Send email
  • RDBMS: Log to a database
  • RollingLogFile: Log to a file, roll to a new file at specified time/size

Documentation can be found on the log4cxx doxygen pages.

Impact to ITK

  • Augment the Error and Warning macros in ITK
  • Can be implemented in New and/or Type macro
  • Immediately available to all class developers
  • Flexible output options
  • Aid to debugging

Pros

  • Allow much more flexibility in logging messages
  • Easy configuration of logging structure
  • Applications can leverage feature
  • Can change logging options at runtime, not compile time

Cons

  • Static class variable per class. Experience have proved Singletons to be conflictive when dealing with shared libraries.
  • The library is in version 0.93. Its developers have gone through a refactoring process and the new version depends on a systems service library from Apache.
  • 30K lines of code to maintain
  • 2 Megabytes of source code
  • It wasn't supported in all the ITK platforms. It required substantial work to port it to all of them.
  • Need to work out default configuration
  • Run-time overhead (fairly minimal)

Proposed Plan

  • Check into Insight/Utilities
  • Write smoke test
  • Get test working on all platforms
  • Resolve integration issues (itkNewMacro / itkTypeMacro)
  • Replace Error / Warning Macros
  • Begin using in existing and new classes


Option of Writing our own

This option involves to develop a set of new ITK classes intended for providing the logging functionalities.

Pros

  • Complete control over the code
  • Only implements what we need
  • Focus on performance on the context of ITK uses

Cons

  • Potentially reinventing the wheeel

Potential Implementations

= Adapt IGSTK classes

Sohan Rajan from the ISIS Center at Georgetown University has already develop a starting framework for providing logging capabilities. We could take these classes and extend them as appropriate in order to fulfill the needs of the ITK community.