LogFactory not initialized with the right classloader if first log is from the Flyway class #2270
5.2.4 Which version and edition of Flyway are you using?
Upgraded from 5.0.7 to 5.2.4 What did you do?
Normal log messages
What did you see instead? The exception above.
It seems to me that after the change to fluid configuration the default log creator is no longer initialized with the same class loader we use for the Configuration object. I think the default log creator should be using the same class loader as the parameter in the configuration object. If you are using multiple threads then depending on which thread you happen to be you randomly get this error.
As a workaround i make sure the first log is in the main method of my migration script.
The text was updated successfully, but these errors were encountered:
I think there should be a connection between the log factory and the config object. Now the log factory is a singleton but when and where it is created can cause issues.
To reproduce all you have to do is create the config object this migration in a different thread than the main thread, i believe this should be enough, and of cause have some failing migration so the getLog is triggered:
Hit this as well using SBT.
I'm using Flyway to set up the test database. When running tests manually, on the first test run everything is OK, but on the second one I get the exception above. I explicitly initialize
In the first place, does
UPD: It's probably because
- Remove old, unused scripts in `bin/` - Remove old images from release - `test` and `test-bind` are no longer necessary. Test images are in a different repo now - Remove Docker image creation from sbt build config - actual `Dockerfile` files are easier to deal with - Update scripts in `bin/` to utilize new Docker images - Update documentation for changes - Update all Docker Compose and configuration to use exposed ports on the `integration` image (19001, 19002, etc) both inside the container and outside to make testing more consistent irrespective of method - Update FlywayDB dependency to v8 to fix a weird logging bug that showed up during integration testing. See: flyway/flyway#2270 - Add `test/api/integration` Docker container definition to be used for any integration testing - Move `module/api/functional_test` to `test/api/functional` to centralize the "integration-type" external tests and testing utilities - Move functional testing and integration image to the `test/` folder off of the root to reduce confusion with `bin/` and `docker/`