core modules logging

Module Logging

This topic discusses custom logging specific to plugin modules. As part of the bootstrap process, each plugin module can log information about its configuration. The base PluginModule class provides a Log method that can be overridden to add logs to a dictionary:

public override void Log(IDictionary<string, object> moduleLog)
{

}

The module log information will be shown within the logs of the associated plug-in. This example will implement the Log method for the ValidAddressModule created in the last section. The following implements the log method to return a list of distinct IP addresses configured by the discovered IAllowedIpAddresses instances.

Examples.Bootstrapping.CrossCut/Plugin/Modules

public override void Log(IDictionary<string, object> moduleLog)
{
    moduleLog["AllowedAddresses"] = _addresses.SelectMany(a => a.IpAddresses).Distinct();
}

The Log method is passed a dictionary defined with a string key and object result. This allows adding log entries based on projections into anonymous types for a subset of the data managed by the plugin.

Run the WebApiHost process and view the log entry for the plug-in module to validate that the information has been logged:

cd ./src/Examples.Bootstrapping.WebApi/
dotnet run

[IMAGE]

Plugin Module Log Entries

The above image shows the plugin log for the CrossCut core plugin class contained within the Examples.Bootstrapping.CrossCut project. The Blue arrow shows the log details added to the ValidAddressModule class in the above code. In addition to any plugin module custom logs, the bootstrap process also logs the following for all plugin modules:

• Dependent Modules: Any dependent module property references are logged. In the above, the Yellow arrow shows that the ValidRanges property of the AppModuleOne module within the Examples.Bootstrapping.App plugin references the plugin module service of type ICheckValidRange.
• Discovered Properties: The bootstrap process also logs all module properties referencing collections of instantiated IKnownPluginType objects. The Green arrow in the above image shows the property named AllowedAddresses contains a collection of IAllowedIpAddresses known-type instances. The discovered known-type concrete classes are listed.

Accessing Composite Log

While each plugin is logged, the complete composite-log can be retrieved as a single document. The microservice generated from the solution template is bootstrapped to expose a URL that can be called to return the compose-log document when executing in Development. Execute the following HTTP request to view the log document:

http://localhost:5009/mgt/composite/log

Below is the JSON document rendered using: https://jsonviewer.stack.hu

[IMAGE]

The next section discusses the last phase of the bootstrap process where each plugin module is started and eventually stopped when the host process exits.