Problem
ConfigLoader owns one mutable, process-wide set of static defaults. Builders and final objects consult that state at different points in their lifecycle, which makes configuration timing easy to misunderstand and the implementation difficult to evolve.
The static model also prevents:
- isolated Simple Java Mail configurations within one JVM;
- normal dependency injection and explicit configuration ownership;
- clean separation between application contexts, tests, tenants, or independently configured mailers;
- deterministic construction without first mutating global state;
- a natural Spring integration that binds and injects configuration instead of copying it into a static holder.
The documentation will continue to describe the current safe sequence—load configuration, start a new builder, then build a replacement object—but that is a constraint of the existing design rather than the desired end state.
Direction for 10.0.0
Design an instance-based configuration model that can be constructed, passed around, and injected. The exact API still needs research, but it should aim for:
- an immutable or explicitly snapshot-based configuration object;
- explicit property-source precedence without global mutation;
- a supported way for mailer and email builders, or a configuration-owned factory, to use a configuration instance;
- isolated configurations coexisting safely in one JVM;
- Spring binding and injection through a normal bean;
- a deliberate migration path for the static
ConfigLoader API;
- replacement-object semantics for configuration changes rather than implicit live mutation.
The design must account for every current ConfigLoader consumer: SMTP and operational settings, email defaults and overrides, embedded-image resolution, extra Session properties, and batch cluster configuration.
Design questions
- Should builders accept a configuration snapshot directly, or should a configured factory create builders?
- Can the static API remain as a compatibility facade, or should 10.0.0 remove it?
- Where should system properties and environment variables be resolved?
- How should custom application property sources and framework adapters plug in?
- How should secrets be kept out of diagnostics and object representations?
- What thread-safety and lifecycle guarantees should configuration instances provide?
History
This continues a long line of ConfigLoader-related work:
This issue is intentionally for the larger architectural replacement, not another incremental correction to the static loader.
Problem
ConfigLoaderowns one mutable, process-wide set of static defaults. Builders and final objects consult that state at different points in their lifecycle, which makes configuration timing easy to misunderstand and the implementation difficult to evolve.The static model also prevents:
The documentation will continue to describe the current safe sequence—load configuration, start a new builder, then build a replacement object—but that is a constraint of the existing design rather than the desired end state.
Direction for 10.0.0
Design an instance-based configuration model that can be constructed, passed around, and injected. The exact API still needs research, but it should aim for:
ConfigLoaderAPI;The design must account for every current ConfigLoader consumer: SMTP and operational settings, email defaults and overrides, embedded-image resolution, extra Session properties, and batch cluster configuration.
Design questions
History
This continues a long line of ConfigLoader-related work:
Propertiessupport.This issue is intentionally for the larger architectural replacement, not another incremental correction to the static loader.