-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Add native-image support for Flyway #31999
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
Comments
When this is fixed, i expect more flyway problems. Flyway enumerates migration files from the classpath, which is not supported on GraalVM. |
Stephane will add the proxy hints to Spring Framework, as this proxy hint is not specific to |
I've created a PR to the reachability repo for Flyway. In the tests there is a custom |
Even with the PR merged, Flyway still fails because it thinks there is no SLF4J available and tries to use Log4J2 as a logging system. I created another PR on the reachability repo to fix that for logback. Besides that, i played around with migration finding in a native image (because classpath enumeration doesn't work :/), you can view the code here. I've implemented two approaches:
|
After a review from Stephane: Problems with the PoC: it uses a Another problem is that the code re-implements how Flyway finds the migrations (using classpath enumeration). If would be much better if Flyway would provide an API, which we could call in AOT phase to get the list of migrations, which we then feed into our custom Generally speaking, solution 2 (code generation) is the way to go, solution 1 (index file) can be dropped. Problems with the new approach:
I'm going to investigate how to refactor the PoC to accomodate the changes. |
I've opened / commented on Flyway and GraalVM issues to get Flyway working without us having to write a bunch of workarounds. |
Even if GraalVM team / Flyway team doesn't want to support it by themselves, I found a better workaround than to look for the migrations at AOT phase: Implement a Flyway custom All that is left with this Drawback of that approach is that, when the custom |
I'll put this on hold until either Flyway or GraalVM reacts on the issue. |
So far I got no reaction from the Flyway team regarding GraalVM. I'm currently playing around with Flyway in native-image and may have found a way to use their |
I've got something working here: https://github.com/mhalbritter/sb3-native-flyway-poc-2 There's a ResourceProviderCustomizer which is used when not running in AOT / native image. It's a The |
One caveat: Flyway logs this:
this is due to the fact that the |
Besides the WARN logs, this looks indeed like a viable solution for Flyway support. |
I'm not 100% convinced that the scanner created by NativeImageResourceProviderCustomizer behaves exactly the same as the default one from Flyway. That's the reason I was hesitant to always use the |
This, unfortunately, doesn't remove the warnings from |
The ResourceProviderCustomizer, which is used by FlywayAutoConfiguration gets replaced with NativeImageResourceProviderCustomizer when running in AOT mode. The NativeImageResourceProvider does the heavy lifting when running in a native image: it uses PathMatchingResourcePatternResolver to find the migration files. Closes spring-projectsgh-31999
Came along this warning too, tho all migrations are scanned and applied successfully. Is this just a warning or can it cause issues at later stages? |
I'm not aware of any problems related to the warnings. As I said in #31999 (comment), this is due to the fact that we don't disable the built-in flyway scanner, which doesn't support native-image. |
The Flyway smoke tests currently fail with GraalVM complaining about proxy generation, which could be related to
@FlywayDataSource
:The text was updated successfully, but these errors were encountered: