Description
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
- Create a grails application
- Apply/install GDM
- Create an empty file inside
webapp
- Create a bean configuration that needs to access the file on [3] through it's real path
- 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, [email protected]
- 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.