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 开发者_如何学Pythonthe exploded war folder under webapps has gsp files but not the groovy files.

---

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

---

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.

---

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?