Logging issues

Overview

There are two types of logging to consider in JBossMailServier.  The first is trace logging which maps pretty well to ] and any similar tools.  The second is conversational logging which needs to be considered seperately and may or may not map very well to traditional logging tools.  Trace logging is having the code log its state changes and execution path as well as error and warning reporting.  Conversational logging is reporting on the server and client side communication -- what the client said and how the server responded.

Trace Logging

Trace logging hasn't been implemented and will generally be constrained (which isn't really a problem) to ].

Conversational Logging 

Issues

Conversational logging is somewhat more problematic than trace logging.  For one, it probably needs to be placed in a different log file than trace logging.  Secondly, it needs to be easily disabled at runtime.  Generally trace logging levels are determined at deploy time and only changed if there is a problem.  Conversational logging can be useful for tracing security holes, configuration issues and more.  These might be issues that do not even reside on the server, but with defective or misconfigured mail clients.

Conversational logging needs to be easily digested into server and client side conversation, it must also identify the client which initiated the conversation. 

Implementation Decisions

At the moment, conversational logging is being done through an MBean called MailLog.  A given protocol can be configured to use 0-2 instances of MailLog.  The first instance should handle serverside conversation, the second instance should handle clientside conversation.  However, it is generally more useful to have both the server and client side conversation logged in the same place in order to determine just what the server or client was responding to.  For this reason both serverside and clientside logging will generally go to the same MailLog.  If the MailLog is not provided the protocol should simply not log.

The MailLogMBean provides a runtime "enabled" parameter which determines whether or not the MailLog should write the inputted log information.  Presently it is buffered and may not actually log until it is closed.  We should make the buffer size configurable and provide a "flush to log" operation.  This hasn't been implemented presently.

It may be possible to get Log4j to do what we want (probably wrapped by MailLog); however, it was not obvious that this approach would be more beneficial than simple file output.  This may change if we decide to allow conversation logging to databases or external log stores.

Production systems should prefer to disable conversation logging for performance reasons except in the case of problem resolution.