https://github.com/aspnet/Configuration
Basic change:
I haven't dug too deep but this seems fairly straight forward.
If there's basic agreement, I can start on this.
Ping @jdom, @sergeybykov.
I've not sufficiently investigated Microsoft.Extensions configuration and logging to offer an informed opinion, but in general I very much prefer integrating with existing abstractions rather than maintaining our own.
As this looks related to #2029, my preference would be to address configuration and dependency injection before tackling logging.
I would really like if we move in this direction. Nevertheless, as @jason-bragg mentioned, I believe it's not just a matter of replacing 1 set of configuration objects graph to a different one, but it would probably require a revamp of our config and DI story altogether.
I would really like if we can emulate what AspNet Core is doing today in their config APIs. This way we do not spend countless hours with opinions on what should DI and the config story look like (this is and was always a time sink, as there's a ton of conflicting opinions out there).
AspNet MVC evolved and improved this aspect on every iteration since its inception, and found consensus after tons of debates. So we should just stand on its shoulders, and benefit on the fact that people are familiar with it.
:+1: The more bits we can lift from ASP.NET, the better. Less to learn, more alignment, more developers
I'm glad the consensus is just to reuse what ASP.NET Core is doing since I do the same with my projects at work to avoid debate :)
I think this one I can actually start and see where the rabbit hole goes.
I started with something ugly and basic. I guess I want a pre-review before I keep going down this route:
https://github.com/dotnet/orleans/compare/master...adamhathcock:new_config_2?expand=1
Goal: Make configuration bindable so any file type can be used. Need to separate logic and data.
Changes:
Bindable files:
https://github.com/adamhathcock/orleans/tree/new_config_2/src/Orleans/Configuration/New
Old xml: https://github.com/adamhathcock/orleans/blob/new_config_2/test/TesterInternal/ClientConfig_StreamProviders.xml
New xml: https://github.com/adamhathcock/orleans/blob/new_config_2/test/TesterInternal/ClientConfig_StreamProviders_New.xml
New json:
https://github.com/adamhathcock/orleans/blob/new_config_2/test/TesterInternal/ClientConfig_StreamProviders_New.json
The stuff is far from complete but large TODOs that I see:
ClientFactoryBuilder to take file configs and runtime config then once Build is called then the config is immutable. The act of building will do the logic that is current baked all over the config classes.ClientFactory will create GrainClient objectsThis involves touching a lot of stuff. If M.E.Logging was used then large sections of config would go away (e.g. Trace stuff) I think. But I'd port it over anyway for now.
@adamhathcock OK! Had to try if I really, really can do a PR from your branch. Weird! Is that normal?
On the topic, though, you can do a PR and put your goals there and start a discussion. If you're afraid you run out of time to make progress, well, that's not a problem. Something will be worked out and you don't lose credit for work either. :)
Oh yeah, the actual tests I added:https://github.com/adamhathcock/orleans/blob/new_config_2/test/TesterInternal/ConfigTests.cs#L350
To show the configuration binding to objects.
Okay, I'll just make a PR as a WIP :) Just wasn't sure as this might take me a while.
The new configuration subsystem in Orleans 2.X relies on Microsoft.Extensions.Configuration
Most helpful comment
:+1: The more bits we can lift from ASP.NET, the better. Less to learn, more alignment, more developers