-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Config: detect injected config value mismatch during static init #36281
Conversation
5a47e49
to
6e64941
Compare
50d26a6
to
87b3506
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good, thanks!
Do you thing we'd need a configuration option to turn this into a warning, similar to this:
quarkus/core/runtime/src/main/java/io/quarkus/runtime/configuration/ConfigurationRuntimeConfig.java
Lines 10 to 22 in 2478d22
/** | |
* What should happen if the application is started with a different build time configuration than it was compiled | |
* against. This may be useful to prevent misconfiguration. | |
* <p> | |
* If this is set to {@code warn} the application will warn at start up. | |
* <p> | |
* If this is set to {@code fail} the application will fail at start up. | |
* <p> | |
* Native tests leveraging<code>@io.quarkus.test.junit.TestProfile</code> are always run with | |
* {@code quarkus.configuration.build-time-mismatch-at-runtime = fail}. | |
*/ | |
@ConfigItem(defaultValue = "warn") | |
public BuildTimeMismatchAtRuntime buildTimeMismatchAtRuntime; |
Or is @StaticInitSafe
going to be enough?
In any case I would still have the property default to fail
, that seems safer.
core/deployment/src/main/java/io/quarkus/deployment/steps/MainClassBuildStep.java
Show resolved
Hide resolved
Hm, I think that |
87b3506
to
c02e625
Compare
Agree. The user explicitly tells the mapping with the annotation to be available at |
9b0847f
to
71355bb
Compare
...sions/arc/runtime/src/main/java/io/quarkus/arc/runtime/ConfigStaticInitCheckInterceptor.java
Show resolved
Hide resolved
extensions/arc/runtime/src/main/java/io/quarkus/arc/runtime/ConfigStaticInitValues.java
Outdated
Show resolved
Hide resolved
extensions/arc/runtime/src/main/java/io/quarkus/arc/runtime/ConfigStaticInitValues.java
Outdated
Show resolved
Hide resolved
71355bb
to
0611e6c
Compare
I will send a follow-up PR to update the docs. |
The Native Tests - HTTP job now fails with:
@geoand Is it expected that the value differs? If so I will add |
- record the values injected during static intialization phase - if the runtime value differs from the injected value the app startup fails - also introduce ExecutionMode to easily detect the STATIC_INIT bootstrap phase
- deprecate ConfigInjectionStaticInitBuildItem
0611e6c
to
60c24cb
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Interestingly, I think there are cases where we developers could want to opt out of this check. Most notably, when they don't control the environment their application will run in, like for example the I could imagine a developer setting some generic Quarkus configuration property in their environment variables, because they use that value for all the applications they work on while developing. And then they run So, in the general case this check is great help, but in some edge cases it could be unnecessary and even hurtful. I believe we will have to add a way to opt out on a per-application basis (and not a per-injection-point basis) whether we like it or not. That can certainly be a second step though. Perhaps another approach would be to allow applications (CLIs in particular) to only allow a specific subset of properties to be set through environment variables, ignoring everything else. That sure seems to make sense for the |
This is very confusing The difference is that we would not fail the startup unless the property is used during
Certainly, it should be straightforward to add this functionality.
Yes, CLI is a bit special but still it's confusing... |
Probably we need to provide a way to ignore every check related to build time in the CLI, because the user does not control the build in this case and there is nothing he can do about it. Also, I don't imagine a user trying to set quarkus configuration properties for the CLI (except the ones allowed by the CLI command). So, while it is definitely useful to provide the warnings on a regular application, for the CLI they don't seem to make sense. |
Failing Jobs - Building 60c24cb
Full information is available in the Build summary check run. Failures⚙️ JVM Tests - JDK 20 #- Failing: extensions/hibernate-orm/deployment
! Skipped: extensions/flyway/deployment extensions/hibernate-envers/deployment extensions/hibernate-reactive/deployment and 103 more 📦 extensions/hibernate-orm/deployment✖
|
The JDK 20 job seems to fail repeatedly with
@gsmet Does it ring a bell? |
@mkouba It does for me. Probably the |
Not yet
Sure, the failure isn't related and only happened in one JDK, so it's very clearly a flake. |
@mkouba do you think we should add something to the migration guide? |
That's a good idea but I need to send a separate PR to update the docs first ;-). |
Done. Both ;-) |
- resolves quarkusio#37444 - follow-up of quarkusio#36281
- resolves quarkusio#37444 - follow-up of quarkusio#36281
- resolves quarkusio#37444 - follow-up of quarkusio#36281
- resolves quarkusio#37444 - follow-up of quarkusio#36281 (cherry picked from commit bd98d02)
- resolves quarkusio#37444 - follow-up of quarkusio#36281
This is an alternative to #36169.
The error message looks like:
NOTE: We completely ignore config mappings as they're not available unless annotated with
@StaticInitSafe
.