| Re: [config-dev] Proposal for CDI integration |
In our weekly calls we have agreed that there exists a potential
dependency problem between Jakarta Config and CDI, which (put simply)
amounts to Jakarta Config using CDI APIs while CDI depends on Jakarta
Config to configure itself. Additionally, we generally agree that CDI
should not be required in order to use Jakarta Config, and
particularly should not be required in order to map configuration
groups. This proposal will outline a way which allows CDI to be
optional to Jakarta Config, while still allowing the programmatic API
of Jakarta Config to support complex object mapping, and allowing for
a consistent and intuitive experience with and without CDI.
Please review the entire proposal and, when replying, limit quoting to
the specific points where you have questions or comments.
Part 1: Configuration-to-interface mapping
First, we would provide a configuration mapping mechanism to allow
mapping of multiple configuration properties to a single coalescing
type.
The coalescing type should be defined as an interface. This allows
for simple composability and reuse for common groups of properties,
and also simplifies the requirements on the user.
As an example, consider a simple "hello world" service with a
configuration like this:
public interface HelloWorldConfiguration {
String message();
int repeat();
}
Jakarta Config would provide an API which will implicitly map a
hierarchical section of the input configuration on to the interface,
such that configuration properties correspond to interface methods.
In absence of any other explicit metadata, the name of the
configuration property to map would be derived from the name of the
corresponding interface method. It was discussed that it could be
possible to let the user decide whether to give the typical "get"
prefix for the property or not, based on their preference.
Part 1.1: Annotation usage
Annotation usage should be optional to the maximum extent possible,
using sensible rules to extrapolate default metadata such as deriving
configuration property names from the interface name and its method
names. This minimizes boilerplate. That said, there are sometimes
cases where the defaults are unsatisfactory; for example, the user may
wish to have an element name which does not directly correspond to the
corresponding configuration property. In this case, we could prefer
reusing annotations from Jakarta Dependency Injection. For example:
@Named("hello.world")
public interface MyProgramConfiguration {
@Named("message")
String theHelloWorldMessage();
@Named("repeat")
int theNumberOfRepititions();
}
Another option (in case the Jakarta injection spec is not usable for
this purpose for some reason) would be to introduce specific
annotations within Jakarta Config for this purpose.
Other examples may include annotations to specify conversion behavior,
default values, validation, optionality, etc.
We must not rely on CDI APIs or annotations, otherwise we compromise
the ability of CDI to use Jakarta Config APIs or annotations.
Part 2: Integration with CDI
Integration with CDI may be achieved through several possible
approaches, but they all should have in common that the unit of
configuration injection is the configuration interface. The reasons
for this are manifold: the implementation becomes simpler, and we
clearly separate concerns between configuration and injection.
While it might seem that this would add unreasonable boilerplate for
simple cases, I would contend that this is simpler than what we have
today in MicroProfile Config; consider this example (using MP Config):
public class MyBeanClass {
@Inject
@ConfigProperty("foo")
public String foo;
@Inject
@ConfigProperty("bar")
public int bar;
// ...
}
The drawbacks of the approach are numerous: the user has to specify
the @Inject annotation in order to inform CDI of the injection, and
the @ConfigProperty annotation because the type of the field is not
sufficient to tell CDI what is being injected.
Now consider an approach like this:
@ConfigRoot
public interface MyConfig {
String foo();
String bar();
}
public class MyBeanClass {
@Inject
MyConfig config;
}
All of the relevant configuration is grouped into one object which can
be passed to different program components at will. Increasing the
number of configuration properties does not increase the complexity of
any consumer that does not care about them. And CDI can correctly
identify a configuration interface thanks to a single identifying
annotation on the configuration interface.
Part 2.1: CDI/Configuration dependency solutions
Using this divided approach where configuration mapping is handled
solely by the Configuration implementation and injection is handled
solely by CDI, the integration layer for CDI should be fairly simple.
All injections of interface types which are annotated by the
configuration root annotation are handled as configuration, and that's
the only integration point. The handling would amount to passing the
interface to the configuration API for mapping. Thus the
CDI/Configuration integration could easily reside within CDI itself,
with little risk of problems, resolving any future potential
circularity between Jakarta Configuration and CDI.
--
- DML • he/him
_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org