identified ares of the new logging code that should be removed.  I will
remove them in a future commit so that we can come back to this one if we
decide the removals were too much.

CASTOR framework via the class castor::server:BaseServer.

Constructive feedback, and better still modifications, are warmly welcomed.

LoggerImplementation.  This then allowed me to rename the writeMsg()
suit of functions to logMsg() which is much more clear.

as a parameter.  The functions that create the CASTOR daemon objects all
create a castor::log::LogImplementation object and pass it to the constructor
of their corresponding CASTOR daemon object.  When unit testting, one now has
the posibility to develop a dummy Log object that implements the interface
with dummy or mock routines so that the unit tests can run without having to
write to syslog or rsyslog which is a bit heavy for unit tests.  The
castor::log::LogImplementation basically contains the logging code centered
around syslog that was developed by Sebastien and Dennis.

Please note that I now have to add one or more log functions to the base
class of the CASTOR daemon objects, namely castor::server::BaseServer.

the following MACRO magic in h/log.h:

  #ifdef log
  #undef log
  #endif
  #define log (*logfunc)          /* logging function name                */

With this commit I remove the above MARCHO magic and simply replace "log" with
its expanded form of (*logfunc).

idea being you might simply want to log a message with no parameters.

  /**
   * Writes a message into the CASTOR logging system. Note that no exception
   * will ever be thrown in case of failure. Failures will actually be
   * silently ignored in order to not impact the processing.
   *
   * Note that this version of writeMsg() implicitly uses the current time as
   * the time stamp of the message.
   *
   * @param priority the priority of the message as defined by the syslog API.
   * @param msg the message.
   */
  virtual void writeMsg(
    const int priority,
    const std::string &msg) throw() = 0;

Moved multi process tests into a new binary, as memcheck fails them (a lot of test framework related structures are still allocated at exit time).

Fixed wrong reading of /sys files.
Added unit tests.

unit testing where you might was to use a dummy or mock log object.

Added PTHREAD_MUTEX_ERRORCHECK option to Log mutex, so that mutex misuses get detected (default is blind, undefined behaviour).

Fixed inheritance from std::exception (const correctness of what()). This required declaring m_what mutable.
Created a multithreaded unit test.
Created an automatic exception thrower for unhandled errors.
Ported from previous proof of concept the threading primitves and made them production level (with error checking).
Added unit tests for threading primitives.

Attempt to fix a compilation bug surrounding the uninitialized local variable named len of the method castor::log::Log::writeMsg

implementation of the proposal for a new CASTOR logging system API.

The new API provides a Log class which contains a mutex that mirrors the
previous locking strategy of Sebastien and Denis.  My additional singleton mutex
and functionality should not be in the logging API.  Giuseppe and Sebastien
should decide how the logging API is exposed to subclasses of CASTOR classes
such as Server and Daemon.  The loggin API should concentrate on logging.

By the way, instantiating two Log objects is not actually a problem, they will
simply have separate connections to syslog, that's all.

kindly suggested.

Firstly the instance() method assumes that destroyInstance() is not called
concurrently with it so it can assume that in a multi-threaded scenario there is
a single transition from s_instance being NULL to s_instance pointing to a newly
created Log object.  This means the following mutex-less if statement can be at
the beginning of the instance() method to increase performance:

  if(NULL != s_instance) {
    return *s_instance;
  }

Secondly the destructor of the Log class should be private in order to prevent
clients from being able to directly delete the Log singleton.

collection of functions within a castor::log namespace to a more object
oriented Singleton pattern.  Pleae note that the code is still far from
finished, I am commit (compiling) code early in an attempt to increase feedback.

levels, e.g LOG_INFO, LOG_EMERG.

C++ exceptions and by having a std::string parameter as opposed to a C string.

Fixed (and simplified) backtrace that went wrong when demangling a function name longer than 200 characters.

when dealing with double copy recalls.

Proper fix by defining a new RECALLJOB_SELECTED2NDCOPY state instead
of hijacking the (deprecated) fileTransactionId.