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 listconfig-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://accounts.eclipse.org
|