Modifica codice groovy in fase di esecuzione nell'applicazione Grails

Question

Quando eseguo l'applicazione Grails utilizzando il server jetty incorporato (tomcat for grails 1.2), posso apportare modifiche ai miei controller, servizi e altri file java al volo in fase di runtime senza riavviare l'applicazione. Come posso ottenere la stessa funzionalità sulla mia applicazione distribuita su Tomcat (o su qualsiasi server). Ho osservato la cartella war esplosa sotto webapps ha i file gsp ma non i file groovy.

Answer 1

Completando la risposta di Eric, non è possibile modificare al volo il codice sorgente nell'ambiente di produzione. Tuttavia, se si vuole veramente modificare il codice in Live è possibile:

1. cambiare la classe Groovy, compilarlo, sostituire il file .class nella cartella guerra esplosa e riavviare Tomcat (lo so, lo so, è doloroso ma non conosco un modo migliore)
2. Per i file gsp, c'è un trucco. aggiungi al tuo Config.groovy il file seguente: grails.gsp.enable.reload=true. Questo ti permetterà di cambiare al volo il tuo file gsp. Fai attenzione perché danneggerà le prestazioni. Vedere here per i dettagli

Answer 2

Quando si impacchetta l'applicazione come WAR, i file di Groovy vengono compilati in codice bytecode Java (file .class) e inclusi in WAR. Lo scambio a caldo dei file in fase di runtime non è adatto per l'uso di produzione a causa di perdite di memoria.

Answer 3

Il problema di permgen è specifico per Spring/Grails o lo stesso vale per un setup Tomcat/Groovlet ridotto?

Per quanto riguarda le prestazioni, non vi è alcun vantaggio per il file Groovy compilato rispetto a quello non compilato, corretto? La compilazione è sufficiente per far lavorare Java e Groovy?

Spero che in un futuro non troppo lontano avremo un ambiente di produzione completamente ricaricabile che funziona bene ed è privo di perdite di memoria.

Sembra stupido che Grails & Rails non offrano un'opzione di ricarica di produzione valida (in Grails, chiedendo una prima o dopo la morte del permesso). PHP è apparentemente un cane lento, eppure milioni di siti basati su Apache/PHP offrono contenuti agli utenti in un attimo. Se non stiamo correndo su Facebook, dovremmo preoccuparci delle penalità per le prestazioni di cui siamo avvisati nei campi di * Rails?

Dall'aspetto esterno, il problema del permgen Java in corso sembra assurdo, è irrisolvibile?