Skip to content
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

Flyway should not expect "org/flywaydb/core/internal/version.txt" to be on the custom classpath #1023

Closed
dukeyin opened this issue May 22, 2015 · 10 comments

Comments

@dukeyin
Copy link

@dukeyin dukeyin commented May 22, 2015

If I try to run Flyway 3.2.1 in OSGi and set a different ClassLoader into Flyway, then flyway.migrate() will fail immediately because VersionPrinter requires that an "org/flywaydb/core/internal/version.txt" exists.

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented May 23, 2015

What OSGi container are you using? Our tests pass just fine in Equinox.

Cheers
Axel

@dukeyin
Copy link
Author

@dukeyin dukeyin commented May 24, 2015

I am currently running in Eclipse, but I believe this issue would happen in any OSGi container.

If I do something as simple as

Flyway flyway = new Flyway();
flyway.setClassLoader(getClass().getClassLoader()); // this tells Flyway to use my Bundle's ClassLoader, as opposed to Flyway's ClassLoader, because my SQL scripts are inside my Bundle, not Flyway's
flyway.setDataSource(dataSource);
flyway.migrate();

Then Flyway will always fail because of

VersionPrinter.printVersion(classLoader);
existing:

Caused by: org.flywaydb.core.api.FlywayException: Unable to obtain
inputstream for resource: org/flywaydb/core/internal/version.txt
    at org.flywaydb.core.internal.util.scanner.classpath.ClassPathResource.loadAsString(ClassPathResource.java:84)
    at org.flywaydb.core.internal.util.VersionPrinter.printVersion(VersionPrinter.java:44)
    at org.flywaydb.core.Flyway.execute(Flyway.java:1373)
    at org.flywaydb.core.Flyway.migrate(Flyway.java:1006)

This is because Flyway is expecting "org/flywaydb/core/internal/version.txt" to exist within the custom ClassLoader.

If I instead have Flyway use its own ClassLoader, then of course Flyway can find "org/flywaydb/core/internal/version.txt" within the Flyway JAR, but it will never find my SQL scripts in a different bundle.

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented May 25, 2015

Thanks for investigating. That was incredibly helpful. Consider this fixed in time for the next release.

Cheers
Axel

@Andy-L
Copy link

@Andy-L Andy-L commented Jun 2, 2015

FWIW I am having the same issue running in Felix. Is there a workaround or a recommended alternate approach?

@okharkovskyi
Copy link

@okharkovskyi okharkovskyi commented Jul 20, 2015

Same issue in Felix

@brianduguid
Copy link

@brianduguid brianduguid commented Oct 27, 2015

I'm using Felix. Has a work-around been discovered yet?

@dukeyin
Copy link
Author

@dukeyin dukeyin commented Oct 27, 2015

For now, it would seem that your SQL migrations must be in the same bundle as Flyway (stored in a fragment hosted by org.flywaydb.core, for example).

@brianduguid
Copy link

@brianduguid brianduguid commented Oct 27, 2015

Thank you.

axelfontaine added a commit to flyway/flywaydb.org that referenced this issue Oct 28, 2015
@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Oct 28, 2015

Fixed.

@andrehil
Copy link

@andrehil andrehil commented Nov 19, 2015

Could you please release this fix in version 3?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants