GitLab

Change Type:

• Feature
• Bugfix
• Refactoring

Context and Scope

Currently used (legacy) microservices configuration approach is error-pron, not flexible and poorly scalable:

• The @Value annotation is commonly used. It is redundant, hard to find and change, not type-safe (error-pron);
• Configuration properties (in .property files and @Value) are almost always mapped on capitalized names of environment variables, which reduces the set of possible means of parameter passing and possibility of hierarchic properties definition;
• The unsuitable @Component annotation is commonly used for ostensibly "configuration properties set" classes;

It does not take advantage of the modern configuration methods offered by Spring Boot.

This makes it difficult to transition to a "configuration server/clients" approach usage.

Decision

Extend "Configuration Approach for New Microservices" approach on Existing services.

Existing services' code should be refactored:

• create @ConfigurationProperties annotated beans;
• enable properties beans in modules;
• transform all @Value annotations to @ConfigurationProperties beans fields
  • create property field
    • set correct datatype;
    • compose property field name by properly transforming capitalized @Value's value, eg.: SUPER_PROPERY ==> superProperty
    • optionally: set default value;
  • find that @Value usage in all classes and change it for:
    • inject properties bean into the property consumer class;
    • change @Value variable mentions for propertyClass.propertyGetter;
    • remove @Value definition code;
• correct properties definitions in application.(properties|yaml) files:
  • use the same strategy as for above mentioned "transforming capitalized @Value's value", eg.:
    SUPER_PROPERY ==> super.property

Rational

Current configuration approach is obsolete, error-prone, and hard for understanding maintaining. By establishing a better configuration standard we improve, simplify and speed-up our own development process and make it easier for all new community contributors to join and become involved faster. Plus, we wish to make our services potentially configurable with MSA "configuration server/client" model.

Consequences

• Providers should plan refactoring their code as soon as they slots;
• No urgent activity required. Providers shouldn't sync their changes with others;
• When properties re-defined properly, nothing should break in currently defined CI/CD etc