ConfigFactory has no ability to alter config loading

[pshirshov]

I'm working on system which has control server and a lot of akka-based agents. Each agent asks control server for config at each startup. Server takes default config, renders it and sends to agent.

For now the only way to allow to configure all the typesafe-config based libraries (including akka) is to save this config into file and set config.file system property. It's a very dirty quirk. The only alternative is to configure each library separately (if it exposes corresponding APIs, but for now it's very common to just call ConfigFactory.load()).

The problem is ConfigFactory. It's behavior can't be altered anyhow except of modifying system properties.

I think that acceptable solution for this problem may be implemented with some kind of config loading strategy. To support current config loading protocol such strategy should be implemented as singleton, unfortunately.

If you agree about solution, I may implement a P/R.

[ktoso]

Hi Peter, I'm not quite sure what exactly you would want to configure? Could you provie an example? In Akka itself you can pass in a config during ActorSystem startup, it does not use ConfigFactory.load() then

[havocp]

check out the examples as well which illustrate the intended way that everything should let you pass in a Config

Any kind of registration of global handlers is very fragile (sensitive to init order, classpath order, can conflict across libraries) that's why we avoid it. Kind of an antipattern. Better to pass a Config around.

[pshirshov]

Yep, I know that akka may be configured explicitly. But some libraries can't, unfortunately.

I'm not quite sure what exactly you would want to configure?

I wish to be able to have a single config which all my dependencies may use. For example, if I have some library which relies on ConfigFactory.load() only for now I can't configure it without dirty tricks.

[pshirshov]

Any kind of registration of global handlers is very fragile (sensitive to init order, classpath order, can conflict across libraries) that's why we avoid it. Kind of an antipattern. Better to pass a Config around.

I know, thanks. Just by the way, messing with TS Config under OSGi was a nightmare.

very fragile

But hard-coded constants and using of System.property are antipatterns too. Actually, for now TS Config is fragile too. It breaks when author of some library doesn't provide explicit configuration API. Yep, I know that you not intend such usage but ConfigFactory provokes people to do wrong things.

I don't want to have a singleton, really, but I wish to have a way to alter config loading. You may use System.property to load strategy class for example.

Like -Dconfig.strategy=com.mycompany.CustomConfigStrategy. Generally, this approach should not break under custom classloaders/etc.

[havocp]

A system property which gave the name of a class to be used to load the Config wouldn't be bad, I don't think. That seems ok.

I do think you should file bugs on libraries that don't allow passing in a Config. the docs and examples make it very clear that this should be permitted. Even if you work around it for now it'd be nice to get those fixed.

There's an issue on here discussing osgi but someone who uses osgi needs to work on it, nobody else is quite sure how to test it or what should be done even I don't think.

[pshirshov]

So guys, please find my P/R...

[pshirshov]

P/R merged