Hi,
We made a huge progress at the meeting and finished discussing technical goals. I went through all meeting minutes and created a summary. Before making it official I would like all committers to review it to make sure that I didn’t forget
anything.
Jakarta Config technical goals
-
Programmatic API allowing configuring and using configurations at runtime
-
Annotations based API allowing compile time configuration
-
Meta-config
-
Ability to configure everything programmatically and in an externalized way.
-
It’s a nice-to-have feature.
-
Support for converters
-
In future we will evaluate switch to using Converters specifications when it’s defined
-
Objects mapping must be supported
-
We need to think more about the technical solution
-
We may restrict mappings to interfaces only
-
We must respect java visibility rules (don’t allow writing to private fields)
-
CDI integration
-
CDI integration must be provided but it should be optional. There must be the ability to use Config API without hard dependency on CDI.
-
Allow empty strings and null as values
-
It must be allowed to use both empty strings and nulls as config values
-
There must be an ability to delete a key in a higher level configuration source
-
Jakarta Config must be designed for adoption by other Jakarta EE/MicroProfile specifications including CDI
-
Support for different configuration profiles (dev, test, prod, etc.)
-
Config sources SPI - layered config sources
-
Agreed this SPI is needed
-
We will decide whether to provide parsers to support different format of properties (yaml, properties, json, etc)
-
Support of mutable and immutable configuration sources. It also includes support of configuration sources with unknown/undefined number of properties
-
Mutable configuration sources have some performance drawbacks and complexities
-
We may support only immutable configuration in version 1.0 or we design a model allowing dealing with mutable configuration minimizing (eliminating) drawbacks
-
Support for flat and hierarchical configuration sources
-
Both flat and hierarchical configuration sources must be supported. Rules for converting between tree and flat structures must be defined by the spec.
-
We haven’t decided what representation should be used as a “native” structure of configuration.
-
Provide built-in config source types such as yaml, json, properties
-
Variable replacements, config expressions
-
OSGi
-
Only in manifest, no annotations, etc.
Thanks,
Dmitry
|
