./config/application.properties included in archive

[V. Sevel]

hello,

I created a quickstart app.

at the root of the project I added a config/application.properties file with content:

foo=bar

In the code, I have:

@ConfigProperty(name = "foo")
String foo;

...

log.info("foo=" + foo);

I build the runner: mvn clean install

if I run the runner, it prints the value as expected

then I remove the config/application.properties

and if I run the runner again, it still displays the value, which is not expected

this means that properties available in config/application.properties are picked up during the build and used as build time properties.

is that intended? or is it added by accident?

I guess I did not expect that behavior, because to me nothing other than src/main/resources should be included in the runtime.

[Georgios Andrianakis]

I didn't try it, but are you absolutely certain of this?

It seems very odd that it would be happening.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/2ff0056f-8dd1-4dfa-99fa-8276808ee633n%40googlegroups.com.

[Roberto Cortez]

I’ve just tried it myself and I can confirm the same behaviour.

That source is added both for compile and runtime:

https://github.com/quarkusio/quarkus/blob/e86c231e24e2cf501f269da6d6ef04feb81e7f63/core/runtime/src/main/java/io/quarkus/runtime/configuration/ConfigUtils.java#L70

At this stage, I’m not sure if we should change it. It may cause additional confusion and someone may be relying on that behaviour. Currently, I’m working to make config more flexible and support user defined paths, http resources, etc, which should remove the need to rely on the external config/application.properties file.

Cheers,

Roberto

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-kh1To0WPD-xUUKkh1O1jHZeovyoidQPL93v5f_7aKgtg%40mail.gmail.com.

[V. Sevel]

hello,

>> At this stage, I’m not sure if we should change it. It may cause additional confusion and someone may be relying on that behaviour

I think we should :). it has been time consuming to figure out this behavior.

plus it could be dangerous. my intent was to have properties to support local testing with the runner jar. and I could have had in there: quarkus.vault.tls.skip-verify=true, and disable tls in production I suppose.

it would have been nice also to be able to change the default 'config' directory, with java -Dquarkus.config.dir=my-local-test -jar ...

one other area of improvement for k8s is passing an entire config as a single environment variable. example:

apiVersion: v1

kind: Pod

metadata:

  name: getting-started

spec:

  containers:

  - name: getting-started

    image: getting-started:1.0

    env:

    - name: QUARKUS_CONFIG_PROPERTIES

      value: |

        # Configuration file

        # key = value

        quarkus.datasource.jdbc.url=jdbc:mysql://remotehost:3306/mydatabase?useSSL=false

        foo=bar

or

    - name: QUARKUS_CONFIG_YAML

      value: |

        # Configuration file

        quarkus:

          datasource:

            db-kind: postgresql

            jdbc:

              url: jdbc:postgresql://localhost:5432/some-database

            username: quarkus

            password: quarkus

        foo: bar

this would save the effort to create a config map, and mount the application.properties in the appropriate directory.

Vincent 

[Roberto Cortez]

I’m working on a separate feature to support user defined config locations that should help with these use cases:

https://github.com/smallrye/smallrye-config/pull/431

I believe we could leave application.properties as add these additional mean to load runtime configuration.

Cheers,

Roberto 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/cf750262-cf4e-4a3a-8f75-9326a83b4b97n%40googlegroups.com.

[Stuart Douglas]

Properties that are set at build time become the defaults for runtime, unless they are explicitly overridden.

Stuart

--

[V. Sevel]

>>  Properties that are set at build time become the defaults for runtime, unless they are explicitly overridden. 

Hi Stuart. I don't dispute this. What I argue is that ./config/application.properties shouldn't be part of the build. 

Vincent