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 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

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

Cheers
Axel

@dukeyin
Copy link
Author

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

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

Cheers
Axel

@Andy-L
Copy link

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

Same issue in Felix

@brianduguid
Copy link

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

@dukeyin
Copy link
Author

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

Thank you.

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

Fixed.

@andrehil
Copy link

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
Development

No branches or pull requests

6 participants