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

Exception "Unable to resolve Jdbc Java migrations in location" due to wrong assumption on classloader behavior #1487

Closed
toro01 opened this issue Dec 9, 2016 · 1 comment
Labels
Milestone

Comments

@toro01
Copy link

@toro01 toro01 commented Dec 9, 2016

What version of Flyway are you using?

4.0.3

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin, SBT plugin, ANT tasks)

Java API (JRE 1.7.0.67)

What database are you using (type & version)?

Hsqldb

What operating system are you using?

Windows / Linux

What did you do?

In my project, I had until now only SQL migrations files and everything was running correctly. Now I have also a Java migration file.

What did you expect to see?

I'm expecting that the whole migration runs successfully (ie. migration performed using both SQL and Java migration files)

What did you see instead?

In eclipse, it's running well, but once released, the applications fails to start, with exception "Unable to resolve Jdbc Java migrations in location: classpath:foo/bar"

Root exception is a null pointer in ClassUtils#getLocationOnDisk line 117 and the reason is that a ProtectionDomain is supposed to always have a CodeSource having itself a not null location. In my case, the CodeSource has a null location because I'm using a custom class loader which defines classes by calling URLClassLoader#defineClass(String name, byte[] b, int off, int len) (J2SE standard). In that case, a default ProtectionDomain is used, in which the CodeSource has a null location (see ClassLoader#defaultDomain).

Flyway should not assume that a CodeSource always has a non null location because Java doesn't make this assumption.

axelfontaine added a commit to flyway/flywaydb.org that referenced this issue Jan 31, 2017
@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Jan 31, 2017

Good point! Check added.

@axelfontaine axelfontaine added this to the Flyway 4.1 milestone Jan 31, 2017
pradheeps pushed a commit to pradheeps/flyway that referenced this issue Mar 7, 2017
…n location" due to wrong assumption on classloader behavior
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
2 participants
You can’t perform that action at this time.