This is a specialization of the Injection's that is based upon Helidon's configuration subsystem, and adds support for something called config-driven services using the @ConfigDriven annotation. When applied to a target service interface it will allow developers to use a higher level aggregation for their application configuration, and then allow the configuration to drive activation of services in the Helidon Injection Framework. The @ConfigBean annotation can be used to customize behavior of a type that acts as a config-bean.
See the user documentation for more information.
- api - the config-driven API & SPI.
- processor - the annotation processor extensions that should be used when using ConfiguredBy.
- runtime - the runtime support for config-driven services.
- tests - tests that can also serve as examples for usage.
Config bean can be any type that
- provides a public static factory method
ConfigBeanType create(io.helidon.common.Config config) - is annotated with
@Configured(root = true, prefix = "some.prefix")
By referencing it from @ConfigDriven annotation, the config-driven annotation processor would take note of the bean, and make sure we can discover it at runtime and create instances from configuration.
A config-bean can also have @ConfigBean annotation to control the way bean instances are created (if we want a default instance, if the bean must have a configured option, and if it repeatable).
The expectation is that config-beans are created using helidon-builder-processor, by annotating a Blueprint with Configured annotation, and optionally with the ConfigBean annotation.
Any service annotated with @ConfigBean(ConfigBean.class) is a config-driven service.
Such a service will be added to service registry FOR EACH config bean instance that is discovered from configuration. For repeatable types, each instance has a name obtained from configuration (either the configuration node, or a name property),
as a Named qualifier.