Implement HOCON reference config loading

[Aaronontheweb]

Copy of issue https://github.com/akkadotnet/akka.net/issues/3054

---

In order to better resolve issues like:

https://github.com/akkadotnet/akka.net/issues/3031 https://github.com/akkadotnet/akka.net/issues/3051

I propose that we do the following:

• Standardize on having exactly one reference.conf file per NuGet package and always stored in the same place.
• Automatically scan all assemblies in the same folder as the root Akka.dll and if they match a known assembly name / convention (i.e. core Akka.NET assemblies or Persistence plugins following the Akka.Persistence.* convention), chain those configurations together in a topologically sorted way.
• Prepend the user-defined configuration to that fallback chain.
• Delete all of our configuration loading / injection hacks from the code base.

This is how the JVM does it using the reference.conf files that ship as parts of the JAR files they deliver with each module, loaded via some of the tools in the stand-alone HOCON package: https://github.com/typesafehub/config/blob/master/config/src/main/java/com/typesafe/config/ConfigFactory.java https://github.com/typesafehub/config/blob/master/config/src/main/java/com/typesafe/config/DefaultConfigLoadingStrategy.java#L25

This will avoid many of the issues we have with lots of plugins and forcing the end-user to have to manually include fallbacks for built-in libraries in their bootstrapping code.

[Arkatufus]

The only problem I have with this strategy is that, depending on the platform and build, there is no guarantee where Akka.dll will be located during runtime.

[Aaronontheweb]

yeah, it's definitely going to need to be skunked out via lots of testing.

[Arkatufus]

What do you mean by "topologically sorted way"?

[Aaronontheweb]

Following in the order of its dependencies

I.e. Akka.Cluster --> Akka.remote --> Akka

Sent from my iPhone

On Aug 11, 2019, at 9:55 AM, Gregorius Soedharmo [email protected] wrote:

What do you mean by "topologically sorted way"?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Arkatufus]

Won't that be a problem because each plug-in would have to know all of its dependency ahead of time? And, depending on the dlls found inside the directory, the config loader would have to build the dependency tree during parsing? What about the possibility of a diamond dependency problem? What if 2 plug-ins on the same dependency level uses a common dependency and causes a config override collision?

[Aaronontheweb]

This should probably be an Akka.NET issue, actually. Have a better idea for how to do this with the built-in Akka.NET modules.

[Aaronontheweb]

Another example of where this would have been helpful: https://github.com/akkadotnet/akka.net/issues/5383