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.

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;

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).

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.

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

namespace.

C++ not be strict enough with the use of const.  I hope this commit fixes these
const problems.  There is still another SLC6 I need to tackle in order to get
TramCity to pass the SLC6 build.

until some work is pulled/rebased from the remote master.  Please also note
that more work still needs to be done before this can be used by somebody else.

static (hidden) methods to the castor/log/Log.cpp file:

    castor_openlog()
    castor_closelog()
    castor_syslog()

These three methods are copies of the dlf_openlog(), dlf_closelog() and
dlf_syslog() functions defined in the file CASTOR/dlf/dlf_lib.c.  I have
renamed the associated static global variables using the "s_" naming convention.

Please note that this commit does not finish the implementation of the new
logging API (I here a groan from the back).  Again I'm looking for feedback
(again another groan from the back).

This commit provides an empty implementation.  It's goal it to agree upon the
API which is basically a cut down rip-off of the orginal DLF API.

Isn't DLF already dead? I here you cry, well in line with good CASTOR tradition
I reply both yes and no.  The server side of the Distributed Logging Facility,
effectionately known as the Denis Logging Facility, has been gone for a while.
However both the C and C++ APIs have remained, with the code implementing them
simply sending CASTOR logs to rsyslog.

bug #92460: tapebridged should gracefully shutdown a migration tape-session when tapegatewayd reports a disabled tape

Fixed bad behaviour of tapebridged when it has to cope with a DISABLED tape
just before its request for the first file to migrate.

Improved unit tests.

After further reverse engineering rtcpd it became apparent that there should
only be one configuration parameter to specify which of the following 3 possible
tape-flush behaviours the tapebridged and rtcpd daemons should follow:

  * N_FLUSHES_PER_FILE
  * ONE_FLUSH_PER_FILE
  * ONE_FLUSH_PER_N_FILES

This commit adds the following tapebridge configuration parameter, which today
is ignored:

  TAPEBRIDGE TAPEFLUSHMODE N_FLUSHES_PER_FILE

More importantly and the real reason for this commit is the value of this
configuration parameter is now passed from the tapebridged daemon to the rtcpd
daemon via the tapeFlushMode member of the newly updated TAPEBRIDGE_CLIENTINFO2
message:

typedef struct {
  uint32_t volReqId;
  uint32_t bridgeCallbackPort;
  uint32_t bridgeClientCallbackPort;
  uint32_t clientUID;
  uint32_t clientGID;
  uint32_t tapeFlushMode;
  uint64_t maxBytesBeforeFlush;
  uint64_t maxFilesBeforeFlush;
  char     bridgeHost[CA_MAXHOSTNAMELEN+1];
  char     bridgeClientHost[CA_MAXHOSTNAMELEN+1];
  char     dgn[CA_MAXDGNLEN+1];
  char     drive[CA_MAXUNMLEN+1];
  char     clientName[CA_MAXUSRNAMELEN+1];
} tapeBridgeClientInfo2MsgBody_t;

Please note that the TAPEBRIDGE_CLIENTINFO2 has not been released in any version
of CASTOR and is therefore subject to change until the next release where it
will be frozen.

The tapebridged daemon can now receive TAPEBRIDGE_FLUSHEDTOTAPE messages from rtcpd.  The current tapebridged daemon behaviour on reception of such a messages is abort the current tape-migration session and log a "not implemented" error message.

Merged branches/bridge_bug_80217 into the trunk.