Simplify Extension Classes

[DominikPinsel]

Hello everyone,

I think our extension structure is more complex than necessary. At the time of writing we have the following extension types

• BootExtension
• ConfigurationExtension
• MonitorExtension
• ServiceExtension
• SystemExtension
• VaultExtension

Additionally SystemExtensions have the LoadPhase Default and Primordial.

Please correct me if I'm wrong. But isn't it possible to describe all the dependencies between the extensions using the Require and Provides properties? These two fields provide enough functionality to load all dependencies in the correct order.
Or did I miss something here? If not, I would suggest using only these two properties.

_{Dominik Pinsel [email protected], Daimler TSS GmbH, legal info/Impressum}

[MoritzKeppler]

Some additional questions I'd like to clarify:
Extensions can express dependencies one "feature" level - something on a higher abstraction level as actual services.

• How can a consumer of an extension know the exact services provided by it without looking into the code?
• Which services can be expected to be present without expressing a feature dependency?
• What kind of interactions with another service are allowed during init phase?
  _{Moritz Keppler [email protected], Daimler TSS GmbH, legal info/Impressum}

[MoritzKeppler]

• Created an issue to improve naming of library modules in comparison to extension modules add "-lib" suffix to modules that provide libraries #185
• Created an issue to explore how an annotation on services can be used to state the related feature explore how relation between feature and service can be expressed #186

We furthemore discussed the following rules:

• "An extension can expect that everything from the core is loaded before." (do we need to keep "primordial" extensions for that?)
• "During init of an extension lookup of other services is allowed but no interaction with those." => assume that will not work, e.g. there are registerController calls to WebService extension from init methods.
  Isn't it more like "Interaction with a registered service is allowed even in init phase. Start means that calls from outside are possible (e.g. start to listen to ports etc.)." @jimmarino

_{Moritz Keppler [email protected], Daimler TSS GmbH, legal info/Impressum}

[MoritzKeppler]

Walked once more through the extension loading code. There are still too many different ways services are handled and it's hard to understand if that is on porpuse or if it's just for "historic reasons".
There are "infrastructure" services, like Vault, Monitoring, TypeManager, HttpClient, WebService, Configuration. Those are partially available via explicit getters at the context, partially registered as services (or both). Some of them get created in the BaseRuntime and are then being passed to the context which takes care of register them. Some of them get created by an extension but the ExtensionLoader then executes the registration. Some are handled by CoreServicesExtension, and some act as regular and standalone ServiceExtension.

Would like to document the reasoning and align the behaviour where possible.

[jimmarino]

I think we've discussed why the Vault, TypeManager, Monitor, and configuration are special services. I'll document those when I get back. WebService can be converted to a pure extension, which I will do when I implement this issue.

I'll open an issue related to this and assign it to myself.

[MoritzKeppler]

I'm also fine with putting WebService and HttpClient to the same class of "special extensions / services". For me those are all basic infrastructure services, independent from the core business logic and needed by most of the extensions. Let's have a discussion on that next week.