ILogger

Standard Logger interface and implementation to take the logging responsibility from the CodeProcessor and move it to the ProductKernel.

The logger instance is created by the controller and handed down to the CodeProcessor.

Interface

enum LogLevel
{ 
    Debug, 
    Info, 
    Warning, 
    Error, 
    Critical 
}

interface ILogger
{
    // For Telemetry and other severe events monitoring
    event LogEventOcurredHandler LogEventOcurred;

    // Base methods
    void Log(string message, LogLevel logLevel = Message);
    void Log(Exception ex, LogLevel logLevel = Error);

    // Simplified methods (only invoke to the base methods)
    void LogCritical(string message);
    void LogCritical(Exception ex);
    void LogError(string message);
    void LogError(Exception ex);
    void LogWarning(string message);
    void LogWarning(Exception ex);
    void LogInfo(string message);
    void LogDebug(string message);
    void LogDebug(Exception ex);
}

Levels Explanation

1. Critical: serious errors

2. Error: normal errors

3. Warning: might be a problem or not.

4. Info: normal message to be written in the log.

5. Debug: messages only shown in "Debug' mode.

Logger Configuration through Controller

The controller is the one responsible for creating logger instances in the generic infrastructure:

• By default, loggers only write to a file stream and not the console. This behavior can be overridden by passing a LogConfiguration object to the Controller with a non-null minimumConsoleLevel. This is a common option when creating a CLI bundle.

• By default, loggers are configured to raise the LogEventOcurred event when errors and critical messages are logged. This, in turn, sends telemetry and assessment model messages for those levels. Again, this can be overridden through a LogConfiguration object, setting minimumEventRaisingLevel at the desired level.

Don´t use the standard streams (stdout, stdin, stderr) on Electron GUI bundles. The CGI mechanism for communication between the Electron and .NET uses these streams, so using them might introduce erratic behavior.

Considerations

• One log for the product kernel to report events that occur before and after execution.

• One log for the Code Processor to report events that occur during execution and other specific processes.

• The product kernel logger is handled in a generic folder (%appdata%/Mobilize) and only copied to the output folder until the execution is finished.

• A policy to delete old logs.

Note: policy to delete old logs is not yet implemented.