Can't configure XA Datasource with env vars

[fabiosimeoni]

Hi! Using env vars for config as it plays well with Docker-based microservices.

I seem unable to configure the props a XADatasource with this though:

KUMULUZEE_XADATASOURCES0_JNDINAME=jdbc/apprise
KUMULUZEE_XADATASOURCES0_PROPS_SERVERNAME=db
KUMULUZEE_XADATASOURCES0_PROPS_PORTNUMBER=5432
KUMULUZEE_XADATASOURCES0_PROPS_DATABASENAME=xxx
KUMULUZEE_XADATASOURCES0_XADATASOURCECLASS=org.postgresql.xa.PGXADataSource
KUMULUZEE_XADATASOURCES0_USERNAME=xxx
KUMULUZEE_XADATASOURCES0_PASSWORD=xxx

Initially, I thought I was fumbling with the (awkward) name mappings, but then I checked your sources and noticed that EnvironmentConfigurationSourc#getMapKeys doesn't even try to get into a map like props, which was a surprise.

Am I doing something wrong? thank you.

[fabiosimeoni]

If you confirm this is a known limitation, I'd be happy to move to other forms of configurations, provided that I can feed them at startup, rather than baking them in the uber jar at build time.

But I'm now under the impressions you expect java props and yaml files to be classpath resources right? Or is there a way to mount a config file in some location external to the uber jar?

Sorry, am a bit stuck on this rather core thing, I need XA sources for transactions. Thanks for your guidance.

[jmezna]

You can configure the XADatasource with environment variables, but you still have to provide a default configuration in the config.yaml file. The file will be parsed for the configuration structure, but the actual configuration values will be taken from the environment variables which have higher priority. We are aware of the limitation of this approach and will provide a fix shortly.

You can also mount configuration files outside the classpath resources by specifying the system property -Dcom.kumuluz.ee.configuration.file=/path/to/externalconfig.yaml.

[fabiosimeoni]

now that's a clever approach and it and works a charm, thank you.

and it doesn't seem such a hack to me: the 'embedded' yaml provides at once defaults and structure, reducing runtime overrides to what's actually required. If you then consider the unpalatable syntax of env vars, the less config we need to write the better.

(and yes, I'd been using system props to move forward, but adding many of them inside a docker-compose.yaml - where I launch the uber jar along with its docker container - was really an eyesore and the wrong place to work in).

thanks again!