Error message when JDBC driver is missing is not helpful #22833
Conversation
|
AFAIK, there's no better approach yet. It'd be great if, on the Quarkus side, there would be some kind of ExceptionMapper for the |
quarkus/deployment/src/main/java/org/keycloak/quarkus/deployment/KeycloakProcessor.java
Outdated
Show resolved
Hide resolved
|
Java Distribution IT failures are not related to this PR. |
ghost
left a comment
There was a problem hiding this comment.
Unreported flaky test detected, please review
Unreported flaky test detectedIf the below flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.forms.ResetCredentialsAlternativeFlowsTest#resetCredentialsVerifyCustomOtpLabelSetProperlyKeycloak CI - Forms IT (chrome) |
There was a problem hiding this comment.
@mabartos Is it taking into account the verbose flag?
Otherwise, LGTM.
EDIT: I have a look and did not find a place to extend how exceptions are handled when executing build steps. I'm OK starting with your changes as they have improved a lot already.
vmuzikar
left a comment
There was a problem hiding this comment.
LGTM but let's wait for @pedroigor's approval :)
ahus1
left a comment
There was a problem hiding this comment.
Hi @mabartos - thank you for the change.
The exception message is now cleaned up better than before.
Still, when I run this, I see 1970 trace messages and 433 DEBUG messages which are not helpful to the user. How can that be fixed?
ghost
left a comment
There was a problem hiding this comment.
Unreported flaky test detected, please review
Unreported flaky test detectedIf the below flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.ui.account2.SessionTest#welcomeScreenSsoTimeoutTestKeycloak CI - Account Console IT (chrome) |
@pedroigor When |
@ahus1 You're right, it could be improved as well. I have some possible solutions for that, and I'll try to find the best one. |
mabartos
left a comment
There was a problem hiding this comment.
The complete error log looks as following:
Updating the configuration and installing your custom providers, if any. Please wait.
ERROR: Failed to run 'build' command.
ERROR: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
[error]: Build step org.keycloak.quarkus.deployment.KeycloakProcessor#checkJdbcDriver threw an exception: io.quarkus.runtime.configuration.ConfigurationException: Unable to find the JDBC driver (oracle.jdbc.xa.client.OracleXADataSource). You need to install it.
at org.keycloak.quarkus.deployment.KeycloakProcessor.checkJdbcDriver(KeycloakProcessor.java:254)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:864)
at io.quarkus.builder.BuildContext.run(BuildContext.java:282)
at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1512)
at java.base/java.lang.Thread.run(Thread.java:833)
at org.jboss.threads.JBossThread.run(JBossThread.java:501)
ERROR: Build failure: Build failed due to errors
[error]: Build step org.keycloak.quarkus.deployment.KeycloakProcessor#checkJdbcDriver threw an exception: io.quarkus.runtime.configuration.ConfigurationException: Unable to find the JDBC driver (oracle.jdbc.xa.client.OracleXADataSource). You need to install it.
at org.keycloak.quarkus.deployment.KeycloakProcessor.checkJdbcDriver(KeycloakProcessor.java:254)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:864)
at io.quarkus.builder.BuildContext.run(BuildContext.java:282)
at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1512)
at java.base/java.lang.Thread.run(Thread.java:833)
at org.jboss.threads.JBossThread.run(JBossThread.java:501)
ERROR: Unable to find the JDBC driver (oracle.jdbc.xa.client.OracleXADataSource). You need to install it.
For more details run the same command passing the '--verbose' option. Also you can use '--help' to see the details about the usage of the particular command.
@ahus1 @vmuzikar @pedroigor The TRACE and DEBUG messages are gone, and only the JDBC error message is shown.
For more details about the provided solution, check the comment below.
| Class.forName(dbDriver.get(), false, Thread.currentThread().getContextClassLoader()); | ||
| } catch (ClassNotFoundException e) { | ||
| // Ignore queued TRACE and DEBUG messages for not initialized log handlers | ||
| InitialConfigurator.DELAYED_HANDLER.setBuildTimeHandlers(new Handler[]{}); |
There was a problem hiding this comment.
When an exception is thrown during the execution of the build chain, the log handlers might not be initialized yet, and gathered log records are queued in the QuarkusDelayedHandler. When the queue limit is exceeded, or the minimum log level is set to >=INFO, these TRACE and DEBUG log records are dropped.
When the app crashes after the exception is thrown, the DelayedHandler is closed as well, but it doesn't know how to handle the accumulated log records, because no logger is initialized yet. So, the handler just prints the whole queue of log records to the stderr. As the InitialConfigurator is related to bootstrap, we're not able to programmatically set the queue limit or the discard level in the build chain.
We can just workaround this behavior by setting empty build time handlers, and the queue of log records is cleared.
It might be related to all exception handling for build steps, but I don't want to hide some debug info for the other steps. In this case, we don't obtain any additional valuable info about the JDBC. I don't see any problem with this approach.
Unreported flaky test detectedIf the below flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.x509.X509BrowserCRLTest#loginSuccessWithCRLSignedWithIntermediateCA3FromTruststoreKeycloak CI - FIPS IT (strict) |
ghost
left a comment
There was a problem hiding this comment.
Unreported flaky test detected, please review
ahus1
left a comment
There was a problem hiding this comment.
Thank you, I like the new behavior. Thanks for digging into the details of Quarkus.
|
@ahus1 Thanks for the approval. @vmuzikar @pedroigor It'd be good to fit into the 22.0.2 when we have a chance, right? |
vmuzikar
left a comment
There was a problem hiding this comment.
This approach works for me but I think it's not really ideal to basically suppress all log messages if driver is not found on classpath. However, I don't see many alternatives here except maybe making sure we execute our build step after loggers were initialized. But that might bring its own problems.
LGTM but I'd like an approval from @pedroigor too.
Only log records with the TRACE and DEBUG log levels are suppressed, so I think it's okay.
AFAIK, it's a little bit tricky, but could be investigated more. @vmuzikar Thanks for the approval! |
Closes #22795
Check for the particular JDBC driver is executed before all JPA-related things in order to fail fast.
The execution of the build step during the build phase(augmentation) is negligible.
Before:
After:
I'm wondering why the error is shown twice, but I think it's the standard way Quarkus handles the
BuildExceptions.@ahus1 @vmuzikar @pedroigor Could you check it?