search

deephaven / deephaven-core

Deephaven Community Core
Other
254 stars 80 forks source link

Object based configuration #2471

Open devinrsmith opened 2 years ago

devinrsmith commented 2 years ago

It would be nice to have structured objects serve as the basis for configurable properties. This makes them easier to organize, document, reference, (de)serialize, re-use, and use with dependency injection.

As it is today, configuration is coded on a case-by-case basis against a flat keyspace with an implied hierarchy. A variety of constructs have been created to "make it easy": get<Type>ForClassWithDefault, get<Type>WithDefault, get<Type>, getIntegerArray, getStringArrayFromProperty; but these are incomplete and leave a lot to be desired. Often times code that needs configuration will have their own prefix and looping logic, essentially making them responsible for deserialization logic.

As something concrete, I think we should move towards using the Immutables library to get code generation for immutable configuration objects. This also allows us to get built-in support for Jackson or GSON to get deseralization for "free". (Jackson can use JSON, YAML, TOML, XML, or likely other configuration formats if desired.)

This isn't a proposal to remove Configuration - that would be a much larger issue. Most immediately, we'd do away with .prop files, and rely on .json (or other hierarchical format); Configuration would still be able to resolve from the new format. The jetty / netty main entry points would be the first to get new configuration objects, but hopefully it would also give us the opportunity to consolidate application mode configuration into the fold (instead of continuing to have that be a different thing to configure).

One of the challenges might be "realizing" our configuration dependencies - up until now, we've been able to rely on a "bag" that anything in the code base could access. If we moved to a typed configuration system, it forces us to design the inter-relationship between our components in a cleaner manner. But also, some components may be optional, so from a compile-time standpoint, we can't have a hard-dependency on it - how will those pieces of the system get configured?

Relates to #21

Partial sketches / ideas in #2401, #2417

devinrsmith commented 2 years ago

There might also be benefits when configuring python if there are java objects that can be wrapped, or represented as dataclasses in python.