You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Confusing error messages when JDBC driver not found #230
Just ran into a very confusing situation where I would have saved a good amount of time if the database container classes produced better diagnostic messages. Only about a third of the following concerns the library, but I'll briefly give all the context:
I added a runtime dependency to the PostgreSQL JDBC drivers to my project's build.gradle;
I forgot to click on the IntelliJ button to refresh the configuration, so IntelliJ did not place the driver into my classpath;
My unit test using the PostgreSQLContainer class failed with an error saying that it timed out waiting for the database port to become available.
The problem, as I understood it, is in this line of code (though maybe elsewhere as well):
If this fails with a ClassNotFoundException it will continue retrying the connection and when the timer runs out falsely report that we timed out attempting to connect. The problem is that only some exceptions in connection attempts (e.g., IOException or perhaps SQLException) should lead to a retry—others (like ClassNotFoundException) should lead to an immediate abort and report of the exception that caused the failure.
It might be rather tricky to figure out which exceptions fall into which category, however, given how so much of this might vary between different vendors' JDBC drivers.
@ldcasillas-progreso sorry you encountered a problem here, and thanks for raising it. You're right - the behaviour should be more intuitive.
As you say working out which exceptions are permanent vs retryable might be a bit of work; maybe something for later.
In the short term, how about we include an explicit check that the driver class (returned by getDriverClassName()) can be found on the class path, before even trying to instantiate containers. That seems to cover the most likely scenario of the entire DB vendor JAR being missing.
Activity
rnorth commentedon Nov 20, 2016
@ldcasillas-progreso sorry you encountered a problem here, and thanks for raising it. You're right - the behaviour should be more intuitive.
As you say working out which exceptions are permanent vs retryable might be a bit of work; maybe something for later.
In the short term, how about we include an explicit check that the driver class (returned by
getDriverClassName()) can be found on the class path, before even trying to instantiate containers. That seems to cover the most likely scenario of the entire DB vendor JAR being missing.What do you think?
Modify JDBC driver connection behaviour to fail early if the delegate…