Taking too long to see the output after changing any statements on Grails 5.x

[suzon]

Issue description

After changing any statements/classes, project is recompile those class/es is fine but it takes too long to see the output because, project is acting like Re-Initialize everything from BootStrap.

Is there any way to stop reinitializing from BootStrap?, we just wanted to recompile only those changed class

N.B: We are using IntelliJ Idea with Gradle for the Grails Project

[jeffscottbrown]

Is there any way to stop reinitializing from BootStrap?, we just wanted to recompile only those changed class

It sounds like you are not using a reloading agent but instead are using the default recompile/restart behavior. If that is the case, I don't think there is a way to have BootStrap run the first time you run the app and have not run when the app restarts. I don't think BootStrap knows the difference between "start" and "restart".

[suzon]

It sounds like you are not using a reloading agent but instead are using the default recompile/restart behavior. If that is the case, I don't think there is a way to have BootStrap run the first time you run the app and have not run when the app restarts. I don't think BootStrap knows the difference between "start" and "restart".

@jeffbrown: Thanks for your response, But the main problem is in this project has 600+ Domains & related to Services, Controller as well as other utils. That's why project is taking too long to start and/or reloading. Searching for a better solutions

[purpleraven]

@jeffbrown I faced the same issue. With grails 4 I have used oldstyle springloaded instead of spring-boot-devtools

agent "org.springframework:springloaded:1.2.8.RELEASE"

But grails 5 not supports it anymore. And now after any changes in classes I have to wait 1-2 minutes for context reload (mostly bootstrap and beans loading) in development I start up application by run-app . I have spend some time, but didn't find a way, how to reload changes in 5 sec as before

springloaded in grails 4 have some issues: java 8 only, and fails on changes on classes with @Transactional. But anyway, it better then new spring-boot-devtools behaviour.

   Line | Method
->>  569 | doCreateBean       in org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
|    514 | createBean         in     ''
|    321 | lambda$doGetBean$0 in org.springframework.beans.factory.support.AbstractBeanFactory
|    234 | getSingleton       in org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
|    319 | doGetBean . . . .  in org.springframework.beans.factory.support.AbstractBeanFactory
|    199 | getBean            in     ''
|   1106 | getBean . . . . .  in org.springframework.context.support.AbstractApplicationContext
|     73 | handle             in org.grails.web.mapping.mvc.UrlMappingsInfoHandlerAdapter
|   1040 | doDispatch . . . . in org.springframework.web.servlet.DispatcherServlet
|    943 | doService          in     ''
|   1006 | processRequest . . in org.springframework.web.servlet.FrameworkServlet
|    898 | doGet              in     ''
|    883 | service . . . . .  in     ''
|     82 | doFilter           in grails.plugin.springsecurity.rest.RestLogoutFilter
|    320 | doFilter . . . . . in org.springframework.security.web.FilterChainProxy$VirtualFilterChain
|    127 | invoke             in org.springframework.security.web.access.intercept.FilterSecurityInterceptor
|     91 | doFilter . . . . . in     ''
|    334 | doFilter           in org.springframework.security.web.FilterChainProxy$VirtualFilterChain
|    119 | doFilter . . . . . in org.springframework.security.web.access.ExceptionTranslationFilter
|     64 | doFilter           in grails.plugin.springsecurity.web.UpdateRequestContextHolderExceptionTranslationFilter
|    334 | doFilter . . . . . in org.springframework.security.web.FilterChainProxy$VirtualFilterChain
|    158 | doFilter           in org.springframework.security.web.authentication.rememberme.RememberMeAuthenticationFilter
|    334 | doFilter . . . . . in org.springframework.security.web.FilterChainProxy$VirtualFilterChain
|    170 | doFilter           in org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter
|    334 | doFilter . . . . . in org.springframework.security.web.FilterChainProxy$VirtualFilterChain
|    136 | doFilter           in grails.plugin.springsecurity.rest.RestAuthenticationFilter
|    334 | doFilter . . . . . in org.springframework.security.web.FilterChainProxy$VirtualFilterChain
|     64 | doFilter           in grails.plugin.springsecurity.web.authentication.logout.MutableLogoutFilter
|    334 | doFilter . . . . . in org.springframework.security.web.FilterChainProxy$VirtualFilterChain
|    105 | doFilter           in org.springframework.security.web.context.SecurityContextPersistenceFilter
|    334 | doFilter . . . . . in org.springframework.security.web.FilterChainProxy$VirtualFilterChain
|     58 | doFilter           in grails.plugin.springsecurity.web.SecurityRequestHolderFilter
|    334 | doFilter . . . . . in org.springframework.security.web.FilterChainProxy$VirtualFilterChain
|    215 | doFilterInternal   in org.springframework.security.web.FilterChainProxy
|    178 | doFilter . . . . . in     ''
|     77 | doFilterInternal   in org.grails.web.servlet.mvc.GrailsWebRequestFilter
|     67 | doFilterInternal . in org.grails.web.filters.HiddenHttpMethodFilter
|   1149 | runWorker          in java.util.concurrent.ThreadPoolExecutor
|    624 | run . . . . . . .  in java.util.concurrent.ThreadPoolExecutor$Worker
^    750 | run                in java.lang.Thread

Caused by IllegalStateException: java.lang.NoSuchFieldException: metaClass
->>  422 | lambda$buildPersistenceMetadata$0 in org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
|    694 | doWithLocalFields  in org.springframework.util.ReflectionUtils

[jeffscottbrown]

@purpleraven I understand. I am just addressing the question "Is there any way to stop reinitializing from BootStrap?" and I think the answer is no. I don't know of anything built in that would allow BootStrap to make a distinction between a start and a restart. If you were using a reloading agent, then a restart wouldn't happen, and that is why BootStrap doesn't get re-executed for those scenarios.

[purpleraven]

@jeffbrown is it tehnically possible to add support springloaded in grails 5? Or Grails 5 require java 11? For Grails 4 it was added in one day after request.

[purpleraven]

@jeffbrown I have rechecked springloaded with grails 5. That works same with grails 4: Works, but fails on @transactional annotations. I see new 1.3.0 version on https://github.com/spring-projects/spring-loaded. But the version fully brocken. Any Ideas? Does somebody use it at all? For me java 8 + spring loaded in dev much better then spring boot reload

[Dirk-27]

The only suggestion to avoid the long startup sequence in grails 4/5 without springloaded was to disable the dev-tools so that there is no automaticaly boot start on file changes and to use the ide to compile the classes on the fly -> normal hotspot deployment. But this works only, when you don't change the classes api (which is mostly the case).