Load properties from App.config (or something similar)

[zpbappi]

Currently the Vlingo.Actors/Properties class loads properties/settings from a vlingo-actors.properties file. It needs to be modified to read from any standard configuration provider (such as App.config or Web.config). Please discuss your idea here before starting any implementation.

[ChicagoDave]

There really shouldn't be any configuration in the library. Any data required by the library should be injected when instantiated.

[VaughnVernon]

@ChicagoDave We have a plugin architecture which means you can extend the actor runtime. You can see an example on the Java side. This is what @zpbappi ported intact and why we need the .NET idiomatic implementation.

https://github.com/vlingo/vlingo-actors/blob/master/src/test/resources/vlingo-actors.properties

These configurations can be managed in code, but some prefer file-based configurations, especially for heterogeneous environments.

[ChicagoDave]

So looking into this it seems Microsoft has finally fixed a long-standing broken paradigm where you could only use standard configurations from the App or Web context. There's a new .NET Standard/Core implementation under Microsoft.Extensions.Configuration that allows you to implement a variety of configurations. (https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.configuration?view=aspnetcore-2.2)

[VaughnVernon]

Great! I think @zpbappi settled on Core2, not sure about the minor version (2.1?). I'd like feedback from him and @tjaskula but seems like what we want.

[ChicagoDave]

I'm sure that API is in 2.0 going forward. The vlingo library is in .NET Standard and the unit tests are in .NET Core. .NET Standard is the sharable foundation between all .NET implementations and .NET Core is always directly aligned with it. .NET Core has the command line implementation. (@zpbappi chose well)

[zpbappi]

@ChicagoDave the configuration is not in the library, it is in the test project. I just don't like the fact that we are loading from a fixed file named and formatted in a specific way. I would rather have the freedom to have the configuration in whatever format is more appropriate for the consumer project (web.config, app.config, config.json, fluent config using code, etc). We have to ensure that Vlingo .NET can be used in different environments, regardless of the dotnet runtime they have. This is the main reason for selecting NETStandard. Currently, I am restricting all the libraries to target netstandard2.0. I would, however, like to target lower versions of NETStandard. To do that, I will have to stop using System.Threading.Thread (and, few other classes). I believe we can get there. @tjaskula is tackling the Thread classes. For tests, they are running in NETCore2.0. They can be made .NET Framework, or Mono as well. In theory, it does not matter what the the runtime is, as long as it implements the library's NETStandard version or higher. I have a plan to configure multi-runtime build/test later in our CI. But, it's just not the most important thing right now.

Okay, having stated the whole background and drive, I think I was able to convey that we need a solution that can work with NETStandard2.0 or earlier (better). I would really like to avoid conditional targetting for each different runtime, which can happen if we use something that is not in NETStandard yet.

[VaughnVernon]

@zpbappi Regarding,

I just don't like the fact that we are loading from a fixed file named and formatted in a specific way.

I thought we are discussing the port of vlingo-actors.properties from the Java side. What is your thought about not retaining a similar filename? Are you thinking that .NET would be happy to put vlingo-specific configurations into their own application/service config file(s)? No criticism, only looking for clarification.

[tjaskula]

Just for information, Akka.NET keeps still the same java-ich configuration for reference. Even if we adapt it to .NET we should keep the same keys and hierachies

[zpbappi]

@VaughnVernon I don't have any issue with the file name. And, the current code can actually load and parse settings from the vlingo-actors.properties file. It also supports fluent configuration for plugins. That functionality is there and it should always be there. What it does not support is loading the configuration from an already existing standard configuration file in an application. For example, a popular logging utility Serilog can be configured fluently, as well as from the App.config in my existing application. There are other libraries/tools that support their own configuration along with these two methods (NHibernate configuration for example). I imagined something similar for configuring vlingo.

[JohnnyMaxK]

Hi guys, In my opinion the source file does not matter from the moment we use the .net core configuration library that will convert the key into a string separated with : https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-2.2

In our examples, we can put a the configuration file vlingo actors properties and make an configuration provider for such configuration file structure. The most important is that the vlingo settings object is injected it does not matter if it comes from a configuration file.

The vlingo library must expect the vlingo settings object but must not force the configuration file name or structure.

[tjaskula]

@Johnny-Bee we want the configuration file be idiomatic to .net environnement. For now we have custom code that loads the configuration from the underlying file, so we don't need the provider for that.

[JohnnyMaxK]

I understand.

For my company, we use yaml file for the configuration.

In my opinion, we should just create a json representation of the vlingo settings object. Everything will be loaded into a flatten dictionary in the configuration object. We just have to make an extension method to build and return the vlingo settings instance from the IConfiguration. https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-2.2#bind-to-a-class

[VaughnVernon]

@Johnny-Bee Thanks for your feedback. I will make a few comments and pose questions.

• This configuration is not intended for applications/services built with vlingo. It is only for loading vlingo specific runtime configurations. (@zpbappi brought over the Java properties file format as a quick bootstrap, and not intended for long-term use.) Also, this is entirely unnecessary because the default configuration is programmatic and can be overridden in whole or in part using a fluent API. Still, some people prefer external file configurations to code. I think it's important to respect that. Thus, this comment stands: https://github.com/vlingo-net/vlingo-net-actors/issues/23#issuecomment-454461241

• Given that the current format is temporary and is a means to an end, and that there are programmatic workarounds for it (and a default startup that ignores the file), I don't see this as an important aspect to address soon. If you @Johnny-Bee would like to contribute a better approach based on the following comments, that would be great and much appreciated. Yet, I think contributor time may be better spent on core features. However, as a contributor it's up to you to decide what is important.

• Is JSON/YML a standard, supported way to load configurations? Can you point to an example where Microsoft provides a common API to use JSON/YML? Perhaps Microsoft has see the need to support other consumer file format preferences. I am open to this, but I prefer not to introduce yet another custom configuration format unless it is supported by Microsoft .NET Standard/Core.

• The old App.config is XML, and although that is not great, since it is standard I would prefer to use it over another custom file type. I think that using App.config would require we have our own section in the XML that conforms to our own "schema" but not sure. Even so, the schema could be flat as it is now.

I hope my perspective helps.

[tjaskula]

@VaughnVernon just for reference, I pointed @Johnny-Bee to this specific issue, as it may be a good start. This point is not complicated and could be a good start to get a foot on a ladder.

JSON is standard now in MS

As for the solution I was refereing to replacing the current config files to JSON files with the MS convention so we can get rid of the existing parsing code and use something like:

var config = new ConfigurationBuilder()
    .SetBasePath(Directory.GetCurrentDirectory())
    .AddJsonFile("config.json", optional: true, reloadOnChange: true)
    .Build();

Without going into building custom configuration providers and the like.

@zpbappi Do you confirm ?

[VaughnVernon]

@tjaskula @Johnny-Bee Ah, I didn't know. Sorry to get in the way. Yes, this is a great way to get into the project. Thanks for your help!

[tjaskula]

@VaughnVernon you do well, your questions were relevant

[tjaskula]

Implemented in #60