This could be by way of generic command line argument parsing. The additional config source would have a higher priority than the run-time defaults inherited from the build config, but lower than system property/environment variables.
If this can be implemented like I think it can be (I was thinking that adding some bytecode to io.quarkus.runtime.generated.RunTimeConfig#getRunTimeConfiguration that would check a specific system property and/or an environment variable and if found add a new ApplicationPropertiesConfigSource), then I can take this up as part of an after hours activity :)
First we need command-line argument parsing to be done (I have a WIP branch now). Then it can be done as you say, except it'd be the command line argument values being checked first.
Got it! If you want me to take this after the command-line arguments work is in, feel free to assign it to me.
OK so it seems to exist in some form https://github.com/geoand/quarkus/blob/46dc078de494b331d83d39df8dddcc97e516bf85/core/runtime/src/main/java/io/quarkus/runtime/configuration/ApplicationPropertiesConfigSource.java#L70
But it's not in the Guide https://quarkus.io/guides/application-configuration-guide so on the Schrodinger scale, this feature is more dead than alive. Is config/application.properties our recommended way? If yes can we simply document it.
Yes also, I'll update the Quarkus cheat sheet accordantly
It is the recommended way, but this issue includes setting an alternative location IMO; also there was a user report that there may be circumstances where the filesystem file is not used under native image for some reason. Once all the cases have been chased down, I'll resolve the issue.
@dmlloyd let's document it as it stand (mark it WIP if you want). Because right now, while a common question, there is nowhere to point users to.
Has anyone been able to use an external config file?
I have a uber jar and created the config/application.properties inside the jar dir. Then I run the app using
export QUARKUS_PROFILE=prod; java -jar rest-app-quarkus-server-jpa-runner.jar
But I get the following warning:
ARJUNA048002: Could not find configuration file, URL was: null
Hello guys,
After analyzing the ApplicationPropertiesConfigSource.java, I realized that when running the app from a jar, it ignores the config dir.
Shouldn't it prioritize an existing config/application.properties file instead of loading the file from the jar? I can make that change and provide a PR.
Hi,
It should prioritize the file system properties due to the priority being higher here: https://github.com/quarkusio/quarkus/blob/master/core/runtime/src/main/java/io/quarkus/runtime/configuration/ApplicationPropertiesConfigSource.java#L72
Maybe perhaps you are trying to override a property that is build time only?
I'm just trying to use a different JDBC connection string and other DB-related parameters in the production env. My src/main/resources/application.properties has the dev.quarkus.datasource.url and prod.quarkus.datasource.url variables.
Despite I define the profile to be used by typing export QUARKUS_PROFILE=prod; java -jar rest-app-quarkus-server-jpa-runner.jar, it seems to ignore when running from my uber jar, even if I have the config/application.properties at the jar dir.
If I define a system property, it works fine:
java -Dquarkus.datasource.url=jdbc:mariadb://abc.amazonaws.com:3306/mydb -jar rest-app-quarkus-server-jpa-runner.jar
@geoand, for what I understood, the method you pointed is from the InFileSystem class, which I suppose will be used only when the app is running outside a jar.
When running from a jar file, I suppose the InJar class will be used instead. That class ignores the config/application.properties file.
@manoelcampos I think you have sort of confused things. The InFileSystem and InJar refers to the location of the properties file, not how the application is launched :).
As per your problem, could you supply a reproucer (perhaps with a reproducer containing a README with steps) that I can check over the weekend?
For sure and thanks for the support.
No problem :)
Hello @geoand
In fact, the issue is not what I thought.
I could reproduce it in a sample project available at https://github.com/manoelcampos/quarkus-profiles-issue
There is a README explaining the issue and how to reproduce it.
Thanks.
@manoelcampos nice, I'll take a look today or tomorrow most likely
@manoelcampos I see a few problems with the configuration. First of all the system property is -Dquarkus-profile not -DQUARKUS_PROFILE.
Moreover when using profiles in application.properties you need to prefix them with %, like %dev.quarkus.datasource.url
Oh God. I missed out this %.
Sorry and thanks.
No problem 😊
On Sun, Jun 30, 2019, 14:56 Manoel Campos da Silva Filho <
[email protected]> wrote:
Oh God. I missed out this %.
Sorry and thanks.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/quarkusio/quarkus/issues/1218?email_source=notifications&email_token=ABBMDPYZXBEKASIF7QVKAY3P5CNPJA5CNFSM4G32QPN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY4KVSI#issuecomment-507030217,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABBMDPZN2DE46M3BJ3WSP33P5CNPJANCNFSM4G32QPNQ
.
FYI, for running on the command line with maven, the config directory needs to live in target/classes.
Consider clarifying this in the cheat sheet too, as "current working directory" was not obvious to me.
+1 for allowing this file to live somewhere that doesn't get wiped by mvn clean.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you!
We are doing this automatically to ensure out-of-date issues does not stay around indefinitely.
If you believe this issue is still relevant please put a comment on it on why and if it truly needs to stay request or add 'pinned' label.
I assume that this is covered by your latest config work @dmlloyd ?
No, not yet. The groundwork is there but we really need to get command mode sorted out first, since setting the config file location probably warrants a command line option. We do of course support a config file in a fixed location on the file system for now.
Thanks for the update
I also think that this feature would be very useful. Not just passing an argument at command line, but also via environment variable (which are easier to manage in containers).
I tried to pass the APPLICATION_PROPERTIES environment variable as suggested by the code, but it does not seem to have any effects.