akkadotnet/akka.net

Resolve configurations - aka. clean up the WithFallback mess

Open

#770 opened on Mar 30, 2015

View on GitHub
 (1 comment) (0 reactions) (0 assignees)C# (4,543 stars) (1,035 forks)batch import
configurationdiscussionhelp wanted

Description

Me and @Aaronontheweb had a chat regarding configurations and resolutions of these.

Currently we have this weird scheme of injecting plugin configs with InjectTopLevelFallback The reason for this is that we need the user config to be at the top, the plugin configs in the middle and the default config at the bottom.

(you are free to visualize this in any direction you want, I go from top to bottom ;-) )

userconfig
   | fallback
Persistence
   | fallback
Cluster
   | fallback
Remote
   | fallback
Default

This gets weird when we need to know what plugin that has dependencies to other plugins. But the thing is that each plugin config is isolated with their own sections, except for the akka.actor path where different plugins register new serializers, those are just additative so they do not need to be registered in any specific order.

So what if we see the whole config flow as:

userconfig
   | fallback
(Default + Persistence  +  Cluster  + Remote)

Which in the end could be flattened out to:

(Default + Persistence  +  Cluster  + Remote + userconfig)

That is, we could simply take all the configs and append them, starting with the default and ending with the user config. Merging them into just one big text and then parse that.

We don't need any specific dependency resolution for this, the code becomes far less complex. And debugging settings/configs will be much easier as there is no deep web of fallbacks.

This also brings us to my next question. Should we really specify ActorRefProvider in the config?

Currently, we need to parse the userconfig+default config in order to get what actorref provider we are supposed to use. Once this is done, we start up the specified provider and that can spin up a whole chain of configs and plugins.

I take it that plugins and modules are loaded differently in Java land. But is it really likely that if you have referenced clustering that you then in your compiled application starts editing your config and change the provider to remote or local?

What I'm getting at as in .NET we deal mostly with direct assembly references, shouldn't we just provide the actorrefprovider type up front when creating the system. And completely get rid of the multi step config parsing?

Thoughts on this?

Contributor guide