Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.9
-
None
-
None
Description
Currently, concrete Configuration implementations are directly instantiated using their constructors. How this works in detail depends on a concrete class: some constructors accept initializazion parameters, in other cases only a default constructor is available, and further properties have to be set using set methods.
File-based configurations allow a client to pass in the file to be loaded in various forms (URL, File, file name, etc.). The data is then directly loaded by the constructor which is problematic for various reasons:
- The constructors execute complex operations.
- Loading of the configuration file can fail which will then throw an exception.
- The constructors invoke non-final methods for loading data. (Note: This is not only a theoretical problem but has indeed caused trouble in practice, e.g. when trying to set a default encoding for PropertiesConfiguration.)
- Some properties only take effect when set before loading a configuration file. So when these properties are needed, it is not possible to use a constructor which already performs the load operation. This API is confusing.
As an alternative, a builder-like API can be provided: Client code creates a builder object and sets initialization properties for the Configuration object to be constructed using a convenient (fluent) API. Then a fully initialized Configuration object can be obtained from the builder. The required steps for creating a configuration would be always the same, no matter which concrete Configuration subclass is actually created.
In addition, builders could play an important role when it comes to improving the current reloading mechanisms. For this a separate ticket will be opened.