Customization

Executors

Executors are responsible for executing extension points on extensions and the behaviors attached to it. Different executors can be used for the startup and shutdown phase of the application. An executor must implement IExecutor. There are two executors:

• RunExecutor
• ShutdownExecutor

And here the strategy...

Executables

Executables are the core execution contexts which are executed by the executors. Executables are responsible for calling an extension point and all behaviors attached to it. Normally it should not be necessary to write own executable implementations. One use case could be if you want to special treat some kind of exceptions or log all exceptions thrown by an extension point. To be able to plug in your own executables you must do the following steps:

• Write your own IExecutableFactory
• Write your own ActionExecutable
• Write your own ActionOnExtensionExecutable
• Write your own ActionOnExtensionWithInitializerExecutable
• Provide new IExecutableFactory to the run and shutdown syntax builder in the constructor of the AbstractStrategy.

The executable factory...

And here the strategy...

Extension Resolvers

An extension resolver allows plugging in extensions into the bootstrapper. All extensions which are resolved by the extension resolver are added after manually added extensions. An extension resolver must implement IExtensionResolver and add all resolved extensions to the provided IExtensionPoint.

And here the strategy...

Reporting Context

The reporting context tracks all bootstrapping information during the startup and shutdown phase. If the reporting context creation needs to be customized this can be achieved by overriding the CreaterReportingContext method on the AbstractStrategy. The custom reporting context must implement IReportingContext.

The default reporting context implementation offers several virtual members to overload the creation of the several child context implementations used in the reporting context. It is generally easier to start with overriding the virtual members instead of creating an own reporting context.

ConfigurationSection

Section Name

As already described by convention the class name of the extension is used to determine the name of the configuration section to load. If there is no configuration section per extension (meaning several extensions need to load the same configuration section) or a different configuration section name than the class name needs to be used, the name detection can customized by implementing IHaveConfigurationSectionName on the extension.

Configuration Section Loading

If a configuration section needs to be loaded from another source than the application configuration file, for example from a database, this can be achieved by implementing ILoadConfigurationSection on the extension which needs a special loading mechanism.

ExtensionConfigurationSection

Section Name

See ConfigurationSection / Section Name.

Configuration Section Loading

See ConfigurationSection / Configuration Section Loading.

Configuration value to property conversion

As previously shown the key value pairs loaded from the ExtensionConfigurationSectionBehavior can be automatically set in the properties on an extension with automatic destination type conversion. If a special conversion is needed this can be customized by implementing IHaveConversionCallbacks:

FuncConversionCallback is a small helper class which allows to define a function delegate as conversion callback. Of course the sample above could also be written with the extension itself implementing IConversionCallback.

If the default conversion is not suitable it can be overridden by implementing IHaveDefaultConversionCallback. You also have to provide an implementation of IConversionCallback. The default conversion callback will be called whenever there is no explicit conversion callback defined.