Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MP Data source: cannot override using environment variables #1693

Closed
tomas-langer opened this issue Apr 28, 2020 · 5 comments
Closed

MP Data source: cannot override using environment variables #1693

tomas-langer opened this issue Apr 28, 2020 · 5 comments
Assignees
Labels
bug Something isn't working cdi CDI MP P1

Comments

@tomas-langer
Copy link
Member

Environment Details

  • Helidon Version: 1.4.1
  • Helidon MP

Problem Description

When using CDI integration for data sources, we cannot override some settings using environment variables.

This is most likely caused by approach (such as in AbstractDataSourceExtension line 312) where we iterate through config sources instead of getting the value from config.

This approach may miss environment variable rules.

@ljnelson
Copy link
Member

I'll take a look. Related: eclipse/microprofile-config#431 (comment)

@ljnelson ljnelson self-assigned this Apr 30, 2020
@m0mus m0mus added bug Something isn't working P1 labels May 7, 2020
@m0mus m0mus modified the milestones: 2.0.0, 1.4.5 May 7, 2020
@ljnelson
Copy link
Member

@tomas-langer Looping back to this: is it your opinion that environment variable substitution rules should be housed outside of individual ConfigSources?

@tomas-langer
Copy link
Member Author

@ljnelson - yes, this is done by the environment variable config source (and if you disable it, it should not happen). This also depends on order of config sources (so if your file source is before environment variables source, these rules will not trigger.

The method to get config sources is not intended for obtaining properties. You should always use methods on Config to follow the spec (otherwise you may get values from the wrong place)

@ljnelson
Copy link
Member

Do you know offhand if, in our implementation, the requirement that the set of property names returned by Config#getPropertyNames() be equal to the union of the sets of property names returned by each installed ConfigSource is honored? It would seem if environment variables are aliased based on, among other things, the order of installed ConfigSources this would not be the case.

@ljnelson
Copy link
Member

ljnelson commented Feb 3, 2021

Whoops; never closed this; fixed back in September with #2322

@ljnelson ljnelson closed this as completed Feb 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working cdi CDI MP P1
Projects
Archived in project
Development

No branches or pull requests

3 participants