ctassoni
Jun 10th, 2008, 01:42 PM
Following is the description of a project that (I hope) will soon be accepted on SourceForge. This may be of interest if you've been using Spring's groovy-lang tag, or have been considering Grails.
************
GroovyFlow is a Spring-based project that allows web developers to see the effects of changes in their Groovy code without restarting their servlet engine. In fact, there are two modes of running a web application using GroovyFlow. One is development mode, which offers the aforementioned benefits. The other is production mode.
Specifically, Groovy code inside a configured source root can either be compiled before deploying as a webapp (production mode) or run dynamically using the GroovyScriptEngine (development mode). In the latter mode, a daemon thread searches for file modifications in the source root. If there are any, then a new GroovyScriptEngine is created, and any changes in the source root are visible without restarting the servlet engine.
GroovyFlow supplements, perhaps replaces, the dynamic Groovy support offered as a part of the Spring framework. (See http://static.springframework.org/spring/docs/2.0.x/reference/dynamic-language.html .) That support allows a developer to mark a Spring bean in xml with the groovy-lang tag. Within the bean definition, one may include a refresh-check-delay attribute that allows the bean to reload upon modification.
The limitation, of course, is that each groovy bean must be declared in xml. In contrast, GroovyFlow offers a complete source directory of reloadable Groovy code. Adding a new class requires no additonal xml configuration. Indeed, a new class can be added, and even invoked, while the servlet engine is running.
Thus, GroovyFlow may be particularly useful for any developer who wants to use Groovy in an existing Spring application, and for whom the groovy-lang tag isn't enough. Such a developer can start using Groovy productively with a few small changes to his build process.
GroovyFlow can, in fact, be seen as an intermediate step between Spring and Grails (a full-fledged Groovy-based application framework built on top of Spring). GroovyFlow offers a simple alternative to Grails for any developer who is familiar with Spring and doesn't want the bother of learning a second framework.
With Grails you, the developer, must fit an application into a Rails-like directory structure, and will at some point also need to become aware of how Grails uses, and sometimes hides, Spring. Conversely, GroovyFlow works inside Spring, not on top of it. You choose your directory structure, and there's no layer between you and Spring. So, for example, you can painlessly have your Groovy controllers redirect to Spring MVC, Struts, or any controller type that's supported in the Spring framework. (Of course, if you happen to be working with an existing Spring app, that's not a choice, it's a necessity.)
While GroovyFlow is simple, it offers what I took to be the most important features of Grails. Both GroovyFlow and Grails offer Rails-like pretty urls (i.e., urls where /controllerX/methodY invoke methodY of controllerX.) Only GroovyFlow, however, allows you to create new controllers while your app is running, and to see those controllers work immediately. Both projects allow a drastic reduction in xml. And both support Rails-like interceptors for controllers.
Most importantly, both projects support a development mode in which Groovy classes can be reloaded while the servlet engine is running. In this respect, however, GroovyFlow is probably stronger. Grails depends on deploying to Jetty for its dynamic capabilities, while developers using GroovyFlow do not need to deploy to a second development servlet engine. Also, Grails reloadability is often problematic. I personally have never been able to modify a Groovy file inside Grails' src/groovy directory more than once and have it reload. That's not a unique experience; the Grails forum has several posts from others sharing the same problem. GroovyFlow reloadability works reliably, fulfilling Groovy's promise of quick, iterative development.
GroovyFlow is not intended for developers who are already happy with Grails, which is, it must be said, a very impressive project that brings huge benefits to the Java community. But for developers who are working on pre-existing Spring projects, don't want to learn another framework, or who feel a certain 'flow' while developing, and don't want to break their flow by restarting the server, GroovyFlow offers a new option.
************
GroovyFlow is a Spring-based project that allows web developers to see the effects of changes in their Groovy code without restarting their servlet engine. In fact, there are two modes of running a web application using GroovyFlow. One is development mode, which offers the aforementioned benefits. The other is production mode.
Specifically, Groovy code inside a configured source root can either be compiled before deploying as a webapp (production mode) or run dynamically using the GroovyScriptEngine (development mode). In the latter mode, a daemon thread searches for file modifications in the source root. If there are any, then a new GroovyScriptEngine is created, and any changes in the source root are visible without restarting the servlet engine.
GroovyFlow supplements, perhaps replaces, the dynamic Groovy support offered as a part of the Spring framework. (See http://static.springframework.org/spring/docs/2.0.x/reference/dynamic-language.html .) That support allows a developer to mark a Spring bean in xml with the groovy-lang tag. Within the bean definition, one may include a refresh-check-delay attribute that allows the bean to reload upon modification.
The limitation, of course, is that each groovy bean must be declared in xml. In contrast, GroovyFlow offers a complete source directory of reloadable Groovy code. Adding a new class requires no additonal xml configuration. Indeed, a new class can be added, and even invoked, while the servlet engine is running.
Thus, GroovyFlow may be particularly useful for any developer who wants to use Groovy in an existing Spring application, and for whom the groovy-lang tag isn't enough. Such a developer can start using Groovy productively with a few small changes to his build process.
GroovyFlow can, in fact, be seen as an intermediate step between Spring and Grails (a full-fledged Groovy-based application framework built on top of Spring). GroovyFlow offers a simple alternative to Grails for any developer who is familiar with Spring and doesn't want the bother of learning a second framework.
With Grails you, the developer, must fit an application into a Rails-like directory structure, and will at some point also need to become aware of how Grails uses, and sometimes hides, Spring. Conversely, GroovyFlow works inside Spring, not on top of it. You choose your directory structure, and there's no layer between you and Spring. So, for example, you can painlessly have your Groovy controllers redirect to Spring MVC, Struts, or any controller type that's supported in the Spring framework. (Of course, if you happen to be working with an existing Spring app, that's not a choice, it's a necessity.)
While GroovyFlow is simple, it offers what I took to be the most important features of Grails. Both GroovyFlow and Grails offer Rails-like pretty urls (i.e., urls where /controllerX/methodY invoke methodY of controllerX.) Only GroovyFlow, however, allows you to create new controllers while your app is running, and to see those controllers work immediately. Both projects allow a drastic reduction in xml. And both support Rails-like interceptors for controllers.
Most importantly, both projects support a development mode in which Groovy classes can be reloaded while the servlet engine is running. In this respect, however, GroovyFlow is probably stronger. Grails depends on deploying to Jetty for its dynamic capabilities, while developers using GroovyFlow do not need to deploy to a second development servlet engine. Also, Grails reloadability is often problematic. I personally have never been able to modify a Groovy file inside Grails' src/groovy directory more than once and have it reload. That's not a unique experience; the Grails forum has several posts from others sharing the same problem. GroovyFlow reloadability works reliably, fulfilling Groovy's promise of quick, iterative development.
GroovyFlow is not intended for developers who are already happy with Grails, which is, it must be said, a very impressive project that brings huge benefits to the Java community. But for developers who are working on pre-existing Spring projects, don't want to learn another framework, or who feel a certain 'flow' while developing, and don't want to break their flow by restarting the server, GroovyFlow offers a new option.