Модификация Groovy кода во время выполнения в приложении Grails - PullRequest
9 голосов
/ 03 мая 2010

Когда я запускаю свое приложение Grails с использованием встроенного сервера Jetty (Tomcat для Grails 1.2), я могу вносить изменения в свои контроллеры, службы и другие файлы Java на лету во время выполнения без перезапуска приложения. Как мне добиться такой же функциональности в моем приложении, развернутом на Tomcat (или на любом сервере)? Я заметил, что в папке с разнесенными файлами в webapps есть файлы gsp, но нет файлов groovy.

Ответы [ 3 ]

9 голосов
/ 04 мая 2010

Завершая ответ Эрика, вы не можете на лету изменить исходный код в производственной среде. Однако, если вы действительно хотите изменить свой код вживую, вы можете:

  1. Измените класс groovy, скомпилируйте его, замените файл .class в разобранной папке war и перезапустите tomcat (я знаю, я знаю, это больно, но лучшего способа не знаю)
  2. Для файлов gsp есть хитрость. Добавьте в ваш Config.groovy файл следующее свойство: grails.gsp.enable.reload=true. Это позволит вам на лету изменить ваш gsp файл. Будьте осторожны, потому что это повредит производительности. Подробнее см. здесь
3 голосов
/ 04 мая 2010

Когда вы упаковываете свое приложение как WAR, файлы Groovy компилируются в байт-код Java (файлы .class) и включаются в WAR. Горячая замена файлов во время выполнения не подходит для производственного использования из-за утечек памяти.

1 голос
/ 11 февраля 2011

Является ли проблема permgen специфичной для Spring / Grails или будет такой же в урезанной установке Tomcat / Groovlet?

С точки зрения производительности, скомпилированный файл Groovy не дает никаких преимуществ по сравнению с некомпилированным, верно? Шаг компиляции только для того, чтобы Java и Groovy работали вместе?

Я надеюсь, что в недалеком будущем у нас будет полностью перезагружаемая производственная среда, которая работает хорошо и без утечек памяти.

Кажется глупым, что Grails & Rails не предлагают никакой жизнеспособной возможности перезагрузки производства (в Grails, требуя ранней или поздней смерти permgen). PHP явно медлительный, и все же миллионы сайтов, управляемых Apache / PHP, доставляют контент пользователям в одно мгновение. Если у нас нет Facebook, должны ли мы заботиться о штрафах за производительность, о которых нас предупреждают в * Rails camps?

Если смотреть со стороны, то постоянная проблема Java permgen кажется абсурдной, это неразрешимо?

...