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).

[jeffscottbrown]

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).

@Dirk-27 Are you saying that without springloaded that if you disable devtools, that you can recompile the classes in the app using the IDE and as long as you don't change the api that code changes in those classes will be reflected in the running app, without a reloading agent involved?

[purpleraven]

@jeffscottbrown by JVM hot Swapping that possible

[Dirk-27]

@Dirk-27 Are you saying that without springloaded that if you disable devtools, that you can recompile the classes in the app using the IDE and as long as you don't change the api that code changes in those classes will be reflected in the running app, without a reloading agent involved?

@jeffscottbrown : It is long ago I wrote this. It should be possible. We currently are on grails 4.0.13 with configured springloaded and it works like in grail3: change the source, save and it compiles and deploys immediatly. But it works only, when we start with gradle bootRun. So this is our way now. We are still waiting for a grails 5 solution.

[purpleraven]

@Dirk-27 on grails 5.3 I'm using spring loaded by modification of bootRun

bootRun {
  ignoreExitValue true
  jvmArgs(
      '-Dspring.output.ansi.enabled=always',
      '-noverify',
      '-XX:TieredStopAtLevel=1',
      '-Xmx2048m',
      '-javaagent:lib/springloaded-1.3.0.BUILD-20210404.024037-2.jar')
  sourceResources sourceSets.main
  String springProfilesActive = 'spring.profiles.active'
  systemProperty springProfilesActive, System.getProperty(springProfilesActive)
}

springloaded-1.3.0.BUILD-20210404.024037-2.jar works with grails 5

[jeffscottbrown]

@jeffscottbrown by JVM hot Swapping that possible

I thought swapping required a swapping agent. Is it the case that without configuring a swapping agent and with devtools disabled, you are able to make changes to your classes in your Grails app and recompile them using the IDE and as long as you don't change method signatures, you are able to see the effects of those changes in the running app without restart?

Thank you for the info!

[Dirk-27]

I thought swapping required a swapping agent. Is it the case that without configuring a swapping agent and with devtools disabled, you are able to make changes to your classes in your Grails app and recompile them using the IDE and as long as you don't change method signatures, you are able to see the effects of those changes in the running app without restart?

Thank you for the info!

As I know this uses the build in hot deploy functionality of java. Even when you have a war deployed in a tomcat you can deploy another war without shutting down the server. The same happens when the ide compiles the code to the running java class files.