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

Appengine & ClassPathScanner : throw AccessControlException since 4.1.0 #1627

Closed
Ctrl-X opened this issue May 10, 2017 · 1 comment
Closed

Appengine & ClassPathScanner : throw AccessControlException since 4.1.0 #1627

Ctrl-X opened this issue May 10, 2017 · 1 comment

Comments

@Ctrl-X
Copy link

@Ctrl-X Ctrl-X commented May 10, 2017

What version of Flyway are you using?

4.2.0

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin, SBT plugin, ANT tasks)
  • Flyway Java API
  • Maven dependencies
  • Appengine (latest SDK, 1.9.51) Standard Environment (JAVA 7) .
What database are you using (type & version)?

MySql 5.6.23

What operating system are you using?

Mac OSX El Capitan

What did you do?

Only append in the Development environment (as appengine libs are in a different classpath on Google Appengine server)

Basic configuration of flyway:

  • appengine Java helloworld project
  • resources/db/migration/V1_init.sql
  • fresh & clean database (only one table)
  • Add java Flyway migration in a simple servlet:
  Flyway flyway = new Flyway();
  flyway.setDataSource(url,user,password);
  flyway.migrate();
  • Result : Throw an exception :

org.flywaydb.core.api.FlywayException: Unable to scan for SQL migrations in location: classpath:db/migration

I've hunted the bug down to the location where it occurs :
In fact, when the ClassPathScanner try to findResourceNames, it hits the appengine sdk jar (in my case 'appengine-agentruntime.jar') that triggers a :
java.security.AccessControlException: access denied ("java.io.FilePermission" "/Users/CtrlX/google-cloud-sdk/platform/google_appengine/google/appengine/tools/java/lib/impl/agent/appengine-agentruntime.jar" "read")

Basically, after some research, appengine disallow that type of action (opening appengine jar at runtime) and so it raise that FilePermission exception.

This is due to this commit that change the logic of method findResourceNames by adding:

    ...
    try {
       jarFile = new JarFile(url.toURI().getSchemeSpecificPart());
    } catch (URISyntaxException ex) {
       // Fallback for URLs that are not valid URIs (should hardly ever happen).
        jarFile = new JarFile(url.getPath().substring("file:".length()));
    }
    ...

It doesn't catch the AccessControlException, and the exception bubble up to Scanner.scanForResources, eventually transformed into a FlywayException.

For those how have the same issue :
The bug appear in the release 4.1.0, so as a work around, you can use a previous version of flyway (like 4.0.3)

What did you expect to see?

Jar that trigger FilePermission exceptions should be ignored or just warned.

What did you see instead?

FlywayException encapsulating an AccessControlException

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented May 10, 2017

Thanks for the detailed investigation!

michelau added a commit to michelau/flyway that referenced this issue Jun 5, 2017
Some environments (like the Google App Engine Jetty Dev Server) pull
in JAR's from the host system that are not allowed to be scanned at
runtime.  This causes an AccessControlException to be thrown by
java.security, which aborts the classpath scan completely and causes
Flyway to fail.  These JAR's will never have DB migrations in them,
so the failure is unnecessary.  Let's catch this exception and just
warn the user instead.
axelfontaine added a commit to flyway/flywaydb.org that referenced this issue Nov 26, 2017
dohrayme pushed a commit to dohrayme/flyway that referenced this issue Feb 3, 2020
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