Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [config-dev] Technical goals summary
I agree this is a very common and important use case: https://speakerdeck.com/reza_rahman/contributors-guide-to-the-jakarta-ee-10-galaxy?slide=26. However, I imagine this will be implemented some time after an initial Jakarta Config release.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On Aug 16, 2021, at 8:14 AM, grin@xxxxxxxx wrote:



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
_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

Back to the top