Can I ask what is the point of having ApplicationC...
# ktor
c
Can I ask what is the point of having ApplicationConfiguration and ApplicationConfigurationValue wrappers around typesafe objects? They remove access to several other data types, and also to any mechanism of introspection. If I have, for instance, a tier library which expects a Map for its configuration, and if I want to configure it from its own section in application.conf, then I have to do it manually, key/value by key/value... If I want later to add a new configuration parameter, then I'll have to add it both in application.conf and in the conf... My opinion is that having some sort of coercion around configuration types is constructive, but as soon as it has the side effect of adding redundancy somewhere else in the code, it's gone too far. Right now, I think I'm gonna parse a second time the application.conf to get a json out of it, not that I like it but ApplicationConfiguration objects have close the door to every generic configuration handling.
a
So what data type would you want to get from an application config?
c
Okay, forget the data types issue. It's easy to convert anything. But the lack of introspection is more problematic. I can get a list of keys, for instance, but I have no way of knowing if the underlying value is a string or a child config object.
r
ApplicationConfig
is needed to hide underlaying format and not rely on typesafe. For example, in 2.1.0 we will add YAML configs. What methods in API for
ApplicationConfig
you miss? Something like
toMap(): Map<String, Any>
will be sufficient for you? Feel free to create a ticket and maybe API proposal so we can add it.
c
@Rustam Siniukov Thanks, will do.
Done, [KTOR-4416](https://youtrack.jetbrains.com/issue/KTOR-4416/ApplicationConfig-lacks-the-ability-to-export-a-part-of-the-config-to-a-third-party-library), and as noted in the comments, it looks like it's doable as it is, after all.