Pár shell skritpů jsem už napsal - jak pro Windows tak pro Linux, ale v tomto směru se považuji za naprostou lamu a to se ještě nějakou dobu nezmění. Proto jsem fascinovaně naslouchal Dierk Königovi, který na přednášce pražského CZJUGu zmiňoval použití Groovy pro psaní shell skriptů. Vyměnit jazyk proprietárního shellu, ve kterém toho moc neumím, za multiplatformní Groovy, kde jsem na výrazně pevnější půdě, se zdá jako perfektní nápad.
In the last post I described the basic principles I found behind the scenes of GroovyScript refresh. Now imagine that you want to create your own long living Groovy instances with auto-refresh behaviour when source code changes. You can use out-of-the-box Spring support - but there are some limitations I stated in the previous article.
In this post I am going to present an alternative solution that addresses some of the painful issues I noticed.
The first thing one should undestand before he tries to integrate scripting support into his application / framework are class loading issues. One of the main reasons (next to the ability to easily switch from Java) why we have chosen Groovy as our primary scripting language is very good support for live refresh of Groovy classes when source file has changed. But what does Groovy exactly do when it "refreshes" its loaded classes to conform to a newly modified source file?
