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
DropwizardTestSupport not compatible with Failsafe 2.19 #1709
Comments
Thanks for reporting the issue, Gili. Rather than change the type of the
Would you be interested in bringing this change to a PR? |
That could work. Unfortunately this is too elaborate for me to be able to provide a PR for (too busy at work) so I am afraid I will have to leave the implementation to you. |
Hi @Tibor17, I am not actively working on this issue as I have bigger fish to fry at the moment. For now, I am just passively interested in this issue's resolution. |
choose proper configurationSourceProvider for configPath in DropwizardTestSupport
* Allow specifying ConfigurationSourceProvider in DropwizardTestSupport, DropwizardAppRule, and DropwizardAppExtension * Mark constructors with `Optional<String>` for configuration file as deprecated in favor of nullable versions * See https://rules.sonarsource.com/java/RSPEC-3553 * Better exceptions when initializing the test application fails * Clean up tests and remove redundant test applications Closes #1709 Closes #1830
* Allow specifying ConfigurationSourceProvider in DropwizardTestSupport, DropwizardAppRule, and DropwizardAppExtension * Mark constructors with `Optional<String>` for configuration file as deprecated in favor of nullable versions * See https://rules.sonarsource.com/java/RSPEC-3553 * Better exceptions when initializing the test application fails * Clean up tests and remove redundant test applications Closes #1709 Closes #1830
Failsafe 2.19 now runs tests out of JAR files: https://issues.apache.org/jira/browse/SUREFIRE-855
DropwizardTestSupport assumes that
configPath
can be a String (the file path) but this isn't possible for config files located inside JAR files.The only way I can think of fixing this is to replace
String configPath
with a URI, then open anInputStream
to read the config file whether it resides in target/classes or inside a JAR file.However, you just released version 1.0.0 and this sounds like a breaking change ;)
The text was updated successfully, but these errors were encountered: