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

ServletContext is not really what is should be during dbm scripts #143

Open
4 tasks done
fredgalvao opened this issue Apr 26, 2018 · 5 comments
Open
4 tasks done
Milestone

Comments

@fredgalvao
Copy link

fredgalvao commented Apr 26, 2018

Heads Up: there's a chance this is actually a grails issue, as it is reproducible with grails console too. I wanted to make sure here first, as it's the main scenario I have.

Consider:

  • grails-database-migration = GDM
  • any script from grails-database-migration (I tested with dbm-gorm-diff): DMS
  • main application = MA
  • some plugin used by main application = PLUGIN

Task List

  • Steps to reproduce provided
  • Stacktrace (if present) provided
  • Example that reproduces the problem uploaded to Github
  • Full description of the issue provided (see below)

Steps to Reproduce

  1. Create a grails application
  2. Apply/install GDM
  3. Create an empty file inside webapp
  4. Create a bean configuration that needs to access the file on [3] through it's real path
  5. Run DMS

Expected Behaviour && Actual Behaviour

Issue
The servletContext obtainable through multiple sources/means, during the bean configuration phase, for both MA and PLUGIN, in the context of a DMS, is a org.springframework.mock.web.MockServletContext, even though GDM+MA fires up the "grails application" context in the development profile (spring security is loaded, bootstrap runs, beans register, etc). It should be org.apache.catalina.core.ApplicationContextFacade, or any other implementation of a ServletContext that is properly setup, so that getRealPath (for example) would work.

My issue
I have an application with GDM, and another internal plugin that sets up a bean (easy stuff). On the configuration of this bean, I need to access the real path of something inside src/main/webapp (standard stuff). For run-app or test-app and it's derivatives, it shines: I can access servletContext any way I want [holders, mainContext, bean], and it's a valid instance, and getRealPath returns stuff from where it is, dev or prod.
Then, when I need to run dbm-gorm-diff changelog-bacon.groovy, it fails with a few NPE, caused by the fact that servletContext isn't accessible through all means, and is a mock otherwise.
I've tried many other ways to get the real path to a file there but with no success (this isn't really an issue with the plugin, just colateral damage).

Environment Information

  • Operating System: Xubuntu 16.04.4 LTS, x86_64
  • Grails Version: 3.3.1
  • Plugin Version: 3.0.3
  • Database: PostgreSQL 10.3, driver@9.4.1212
  • JDK Version: 1.8.0_152: OpenJDK 64-Bit Server VM (Zulu 8.25.0.1-linux64) (build 25.152-b16, mixed mode)

Example Application

Changes made to the pure grails create-app worth mentioning:

  • logback to file
  • install GDM
  • add @ComponentScan to Application
  • create ImportantBeansConfiguration
  • try to use the bean on Bootstrap

Stacktraces and code snippets

ON DMS

  • on a bean configuration from MA
MABeansConfiguration    : @Autowired servletContext::org.springframework.mock.web.MockServletContext@19921674
MABeansConfiguration    : Holders.servletContext::null
MABeansConfiguration    : ServletContextHolder.servletContext::null
MABeansConfiguration    : @Autowired grailsApplication.mainContext::grails.ui.support.DevelopmentWebApplicationContext@56a4f272: startup date [Wed Apr 25 20:35:35 BRT 2018]; root of context hierarchy
MABeansConfiguration    : @Autowired grailsApplication.mainContext?.servletContext::org.springframework.mock.web.MockServletContext@19921674
MABeansConfiguration    : this.getClass().getResource("/").getPath()::<absolute path to MA>/build/classes/groovy/main/
MABeansConfiguration    : getProtectionDomain().getCodeSource()::<absolute path to MA>/build/classes/groovy/main/
MABeansConfiguration    : this.getClass().getClassLoader().getResource('.')::file:<absolute path to MA>/build/classes/groovy/main/
MABeansConfiguration    : this.getClass().getClassLoader().getResource('/')::null

WARN MockServletContext          : Couldn't determine real path of resource class path resource [src/main/webapp]
java.io.FileNotFoundException: class path resource [src/main/webapp] cannot be resolved to URL because it does not exist
<LONG STACKTRACE I DON'T THINK IS USEFUL FOR NOW>
MABeansConfiguration    : @Autowired servletContext.getRealPath('.')::null

WARN MockServletContext          : Couldn't determine real path of resource class path resource [src/main/webapp/]
java.io.FileNotFoundException: class path resource [src/main/webapp/] cannot be resolved to URL because it does not exist
<LONG STACKTRACE I DON'T THINK IS USEFUL FOR NOW>
MABeansConfiguration    : @Autowired servletContext.getRealPath('/')::null
  • on a bean configuration from PLUGIN
    Same output as on the MA, but with the protection domain returning the location of the jar on maven's cache, which is unrelated to the issue.

ON INTEGRATION TESTS (the output on run-app differs from this only on the path to compiled classes, which is expected)

  • on a bean configuration from MA
MABeansConfiguration    : @Autowired servletContext::org.apache.catalina.core.ApplicationContextFacade@652e64bb
MABeansConfiguration    : Holders.servletContext::org.apache.catalina.core.ApplicationContextFacade@652e64bb
MABeansConfiguration    : ServletContextHolder.servletContext::org.apache.catalina.core.ApplicationContextFacade@652e64bb
MABeansConfiguration    : @Autowired grailsApplication.mainContext::org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@11a95360: startup date [Wed Apr 25 20:52:10 BRT 2018]; root of context hierarchy
MABeansConfiguration    : @Autowired grailsApplication.mainContext?.servletContext::org.apache.catalina.core.ApplicationContextFacade@652e64bb
MABeansConfiguration    : this.getClass().getResource("/").getPath()::<absolute path to MA>/build/classes/integrationTest/
MABeansConfiguration    : getProtectionDomain().getCodeSource()::<absolute path to MA>/build/classes/main/
MABeansConfiguration    : this.getClass().getClassLoader().getResource('.')::file:<absolute path to MA>/build/classes/integrationTest/
MABeansConfiguration    : this.getClass().getClassLoader().getResource('/')::null
MABeansConfiguration    : @Autowired servletContext.getRealPath('.')::<absolute path to MA>/src/main/webapp
MABeansConfiguration    : @Autowired servletContext.getRealPath('/')::<absolute path to MA>/src/main/webapp/
  • on a bean configuration from PLUGIN
    Same output as on the MA, but with the protection domain returning the location of the jar on maven's cache, which is unrelated to the issue.
@fredgalvao
Copy link
Author

Relates to #125

@fredgalvao
Copy link
Author

Maybe relates to #141

@jameskleeh
Copy link
Contributor

Upload an example project that reproduces the issue. I don't think the two issues you linked to are related to anything with the servlet class

@fredgalvao
Copy link
Author

The stacktrace on #125 is exactly the same, that made me think they were related. I supposed the grails version support could relate because this seems like the execution context for the scripts on this plugin doesn't match 100% of what's needed from grails (similar to what unit tests do).

@fredgalvao
Copy link
Author

fredgalvao commented Apr 26, 2018

@jameskleeh Updated the main post with the Example Application section. Minimal changes to the pure grails shell, and results are exactly the same.

@puneetbehl puneetbehl added this to the 3.0.5 milestone Aug 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants