Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Modifying groovy code at runtime in grails application

When I run my grails application using embedded jetty server(tomcat for grails 1.2), I can make changes to my controllers, services and other java files on-the-fly at runtime without restarting the application. How can I achieve the same functionality on my application deployed on Tomcat(or any server) for that matter. I have observed the exploded war folder under webapps has gsp files but not the groovy files.

like image 877
Paras Avatar asked May 03 '10 19:05

Paras


3 Answers

Completing Eric's answer, you cannot change on the fly the source code in production environment. However, if you really want to modify your code in live you can:

  1. Change the groovy class, compile it, replace the .class file in the exploded war folder and restart tomcat (I know, I know, it's painful but I don't know a better way)
  2. For gsp files, there is a trick. add to your Config.groovy file the following property : grails.gsp.enable.reload=true. This will allow you to change on the fly your gsp file. Be careful because it will hurt performance. See here for details
like image 135
fabien7474 Avatar answered Nov 07 '22 09:11

fabien7474


When you package your application as a WAR, the Groovy files are compiled to Java bytecode (.class files) and included in the WAR. The hot swapping of files at runtime is not suitable for production use due to memory leaks.

like image 39
Eric Hauser Avatar answered Nov 07 '22 09:11

Eric Hauser


Is permgen issue specific to Spring/Grails or would the same hold true in a stripped down Tomcat/Groovlet setup?

Performance-wise, there is zero benefit to compiled Groovy file vs. non-compiled, correct? Is the compilation step just to get Java and Groovy working together?

I hope in the not-too-distant future we will have a fully reloadable production environment that performs well, and is without memory leaks.

Seems silly that Grails & Rails both offer no viable production reload option (in Grails, asking for a sooner-or-later permgen death). PHP is apparently dog slow, and yet millions of Apache/PHP driven sites deliver content to users in a snap. If we're not running Facebook, should we care about the performance penalties that we're warned of in *Rails camps?

From the outside looking in, ongoing Java permgen issue seems absurd, is it unsolvable?

like image 1
virtualeyes Avatar answered Nov 07 '22 08:11

virtualeyes