Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [config-dev] Technical goals summary

Fwiw: 

*) both are valid use cases
*) both can be worked around with 1 additional property per config key. E.g. MySQL does it similar for accounts without any passwords you have to pass an 'anonymous' flag

LieGrue,
strub

Am 17.08.2021 um 17:39 schrieb Emily Jiang <emijiang6@xxxxxxxxxxxxxx>:

Hi Dmitry,

As far as I know, I don't think we reached any conclusion on the following. I think we have not reached the conclusion on whether empty is a valid value or not.

  • 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

 

For the OSGi part, I was not in last week's meeting. I would like to discuss more on what it means in the following bulletin. For me, we should semantic versioning Config APIs by using OSGi semantic versioning rules. We can further the conversation on other OSGi adoption. I think it is important for OSGi folks to adopt Config spec. 
  • OSGi
    • Only in manifest, no annotations, etc.
Thanks
Emily


On Mon, Aug 16, 2021 at 12:11 PM Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:

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


--
Thanks
Emily

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


Back to the top