Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [config-dev] Technical goals summary
  • From: grin@xxxxxxxx
  • Date: Mon, 16 Aug 2021 14:14:01 +0200
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NDNck3ERR94pHrlZISShWa0FnGtcTgVM3JAaDIJ/Pyk=; b=JeslPfmQgjqCutoe6YKYBFhuAJPscSkrQ/tnNpuXphTa08003KnJ0fY2PPqYBUnG8q/8hx3TSS3IiZuFE1asuY/+zF/uTgNJdj+1o1aAoPzKBOaKL2ovRsehozBfl4fO3J4koJ88PXaPkpUC/OSHxtz1M+0mxo7C17ZvX4RuasiunQyUv2w2t0t4GAwz79jd6ETtDaTLaHlYxEyVLowTFA6vl7By1eM8RfQlCSsf1TT8aF8f5Mewv7MzdMn5U4TdxzrMWLWzYTCe53vV+FMVOH6x4g86Npjg8TfnzCrUezIsqGmW8ckSfXYwacD14u8uMxp2xoPBqtVDHifZssmihg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=SdJ0yqeUMWwq4WBTW92ii2t/KKjYWFg4lvuIeQspQ+Nz2JOJk5jFhL7GNmLTBZNAZH/hKw9gBvxm5IbjCMAG6HSmNk+uVevni2uSWmMxKZiIIxd04AjtxgpuQG86+yap3oVqvWAdMicyX0l/r5i7i5fuqSCo0mzMik3UAfaTncfFrdPfESZfVibAZw4kYTuluvOZLZgw6GwEsceFeIqi3D/0qlgcyFO+Fo4DmDzCKV34UOnqsME5He4v5dID39yTGVqN+TVXQ46KkqBbuqLDrxDc0rzcyRiaM5JFTtYMu0czD71YRlJTIncKUPSoFQQuMMMlRHodGq9L0CBjmlQbBA==
  • Delivered-to: config-dev@xxxxxxxxxxx
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0

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.



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



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.




config-dev mailing list
To unsubscribe from this list, visit

Back to the top