quarkus.flyway.locations re-read at runtime

[knutwannheden]

Describe the bug

The quarkus.flyway.locations property is a build-time property and as such should only be read at build-time. We have however noticed that the property is re-read at run-time and as a result it is unclear exactly what the behavior will be.

Since we actually have a use case where we would like to be able to change the property at run-time, I am unsure what the course of action should be. I think it would make sense to analyze and fix the bug in the scope of this issue and then if you think our use case makes sense, I can report a separate feature request to change the property into a run-time property.

As for the use case: We run integration tests where we run the Docker image produced by the Quarkus build. Here we sometimes want to add some database migrations (e.g. create test data), which we wouldn't do in production mode. Granted, we can already in the production value for quarkus.flyway.locations reference a file system location (within the Docker container) which doesn't even have to exist and then mount a volume for the migrations we need in our integration tests.

Expected behavior

The quarkus.flyway.locations property should not be overridable at runtime.

Actual behavior

At run-time the quarkus.flyway.locations property is re-read. So if it at launch of the application was set as a system property or environment variable, that value will be read.

How to Reproduce?

I haven't created a reproducer, but if you need one I can look into that.

1. Create a Quarkus application using the Flyway extension
2. Build the application (producing the JAR)
3. Set a breakpoint in the constructor of FlywayContainerProducer
4. Start the application from the command line using java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 -Dquarkus.flyway.locations=foo -jar target/quarkus-app/quarkus-run.jar
5. Connect with the debugger
6. When in the debugger inspecting the value of flywayBuildConfig.defaultDataSource.locations the value will be a list with a single entry "foo" in it

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.3.0.Final

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @cristhiank, @gastaldi, @geoand, @gsmet

[geoand]

So you are essentially seeing a manifestation of #19438, correct?

[knutwannheden]

Yes, that sounds about right. I am however not sure if I saw any warning and in this case not only was the property overwritten, it appears to also "take effect".

[knutwannheden]

Now that #19438 has been fixed, I will take another look at this,

[gsmet]

@knutwannheden friendly ping :)

[geoand]

Closing as out of date. Feel free to comment if this is still an issue

[knutwannheden]

Apparently I cannot reopen the issue, but I just tested this again with Quarkus 2.7.4 and the behavior still appears to be the same. I.e. I can when launching the application override the value of a config property that is supposed to be fixed at build-time.

[knutwannheden]

/cc @geoand

[knutwannheden]

@radcortez I will try to see if #26802 fixes this problem.

[geoand]

@knutwannheden is this problem fixed?

[geoand]

Closing as completed