Move remaining build-time server properties to runtime/defaults

[dimas-b]

The runtime/defaults module is meant as a holder of default Polaris Server runtime properties.

This change moves a few remaining properties from the application.properties file under runtime/server into runtime/defaults to avoid any possible confusion regarding the location of effective server properties.

Note: The Admin tool has its own application.properties file.

Checklist

• 🛡️ Don't disclose security issues! (contact security@apache.org)
• 🔗 Clearly explained why the changes are needed, or linked related issues: Fixes #
• 🧪 Added/updated tests with good coverage, or manually tested (and explained how)
• 💡 Added comments for complex logic
• 🧾 Updated CHANGELOG.md (if needed)
• 📚 Updated documentation in site/content/in-dev/unreleased (if needed)

[flyrain]

Thanks for the PR, @dimas-b !

Would it be possible to move application.properties from runtime/defaults to runtime/server instead? That would align with the approach in the admin module, where the application.properties lives with the runnable modules.

I think this is to consolidate config files from both server and default modules to avoid conflicts. Question on potential user side conflicts, what happens if users add their own application.properties in the binary distribution or Docker image? Would it conflict with the one coming from runtime/defaults, and if so, which one wins?

[dimas-b]

Would it be possible to move application.properties from runtime/defaults to runtime/server instead?

Not in the current state of Polaris module. In other words, it'd be a much bigger refactoring. The polaris-runtime-defaults is reused by runtime/service.

I'd agree that the whole inter-module dependency graph is kind of convoluted at this time, but it's a different concern than disambiguating the source of application.properties.

@flyrain : If you prefer we can tackle the bigger dependency clean-up effort first. Yet, I thought that sorting out Quarkus properties would be a smaller change and might help in the bigger refactoring later.

[dimas-b]

Question on potential user side conflicts, what happens if users add their own application.properties in the binary distribution or Docker image?

Users should not meddle in jar contents. That's where the basic problem of configuration lookup exists (multiple application.properties files on the class path).

Using an external application.properties file has well-defined behaviour and is actually what we recommend in Polaris docs :) https://polaris.apache.org/in-dev/unreleased/configuration/

Downstream builds should not reuse polaris-runtime-defaults from Polaris (which is why it is a separate artifact).

[flyrain]

Using an external application.properties file has well-defined behaviour and is actually what we recommend in Polaris docs :) https://polaris.apache.org/in-dev/unreleased/configuration/

That's good to know. Is the rule of thumb is to avoid multiple application.properties files packaged in Polaris jars?

[dimas-b]

Is the rule of thumb is to avoid multiple application.properties files packaged in Polaris jars?

In my experience it is preferable to have only one application.properties file (including transitive jar dependencies) in each Quarkus application.

Different Quarkus applications (including tests) can have other application.properties files in the same multi-module project, as long as those property files do not end up on the same class path.

[flyrain]

In my experience it is preferable to have only one application.properties file (including transitive jar dependencies) in each Quarkus application.

I agreed that it seems messy if there are multiple application.properties files. Is there any Quarkus doc/issue to document this issue?

[dimas-b]

Is there any Quarkus doc/issue to document this issue?

None, to the best of my knowledge. Please note that "issues" in this case are very tricky to debug and may not always show up.... again, in my personal experience.