Re: [config-dev] Technical goals summary

[grin@xxxxxxxx]

Hi Dmitry,

Is it planned to allow variables whose values are given by Config, in XML deployment files or annotations? For example use ${password) in a @DatasourceDefinition?

Sorry if this message is not sent to the right mailing list.

Regards,

Richard

Le 16/08/2021 à 13:11, Dmitry Kornilov a écrit :

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

_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org