Jakarta Config is a core spec and should not depend on any other specifications. I like David’s proposal. I don’t see that we need to add Config specific annotations to other specifications such as Common Annotations, @Inject or CDI. We
should define them in Config spec, define what they do and ship them with Config API allowing any injection framework to implement them. I am not a big fun of reusing annotations, so I would possibly name them with Config prefix which makes it clear where
it belongs.
-- Dmitry
From: config-dev <config-dev-bounces@xxxxxxxxxxx>
On Behalf Of Emily Jiang
Sent: Monday, July 5, 2021 11:52 AM
To: Jakarta Config project developer discussions <config-dev@xxxxxxxxxxx>
Subject: [External] : Re: [config-dev] Proposal for CDI integration
Thank you David for the CDI integration proposal! It looks good to me as it moves the dependency from CDI to Injection. By the way, for anyone who was not on the call, the context is that we try to make Config not to depend on CDI so that
CDI can use Config. MP Config has a tighter integration with CDI. With that design, there will be circular dependency between Config and CDI if CDI wants to use Config. Also with this design, there will be a migration path from MP Config to Jakarta Config,
which is very important to the end users. I think with this approach, most scenarios can be satisfied, so CDI injection can come in a later release if needed.
Jakarta Config has different use cases from MP Config. If some features in MP Config works well to satisfy the use cases of Jakarta Config. It is a great plus to take MP Config based on the experience and feedback. There is no need to reinvent
the wheels. However, if the feedback for some MP Config needs to improve, Jakarta Config can rework the design to improve the situation. Hope this helps!
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
--
|
