Java Web Frameworks Increase Support for Auto-Reload
In building software, the speed of the compile-build-test cycle has a significant impact on the productivity of the developer. If a developer must recompile and rebuild the application, redeploy it, and potentially restart the server, this takes time that can slow down the development process.
Some platforms for building web applications, particularly those using dynamic and scripting languages, allow developers to make modifications to the application (code, templates and configuration) and see the results of those changes immediately.
This feature is called different things, such as auto-reload and incremental hot-deployment, and the extent to which platforms and frameworks support something of this nature has an impact on how rapidly developers can develop and maintain a web application.
Auto-Reload in Java
Most Java web frameworks have had some level of support for an auto-reload capability, often starting at the level of a page templating language. For instance, it has long been possible to modify a JSP file within a web application and have the application server detect the change and restart.
As web applications grow in size, the time required to restart the server often increases, and this form of auto-reload may require too much time and have too many limitations, particularly when compared to the competition, such as Ruby on Rails.
With several Java web frameworks having recently announced increased support for auto-reload, InfoQ took the opportunity to catch up with some of the more popular Java web frameworks and compile the results.
Grails supports auto-reloading with some limintations:
All Grails artifacts (controllers, tag libs, services etc.) are reloadable in Grails, however there are some quirks:
- Services can currently only be reloaded if the 'transactional' property is set to false
- Domain Classes are re-mapped to the database at runtime. If the data source is configured to auto-generate the database via the 'update' setting of the 'dbCreate' property it will do its best effort to update the database. This process doesn't always go smoothly however and changing domain classes occasionally require an application restart
Seam 1.2.1 has just introduced what they're calling "incremental hot-deployment":
Only Seam JavaBean components are supported - it doesn't work for entities, and it doesn't (yet) work for EJB3 components. We do plan to support this feature for EJB3 components, but it looks like we won't have time to work on that until after JavaOne.
Spring MVC & Web Flow
Spring 2.0.4 allows a Spring MVC dispatcher to be reloaded. Spring's support for dynamic languages allows controllers and validators to be written in Beanshell and Groovy, and refreshed without restarting the application.
Spring Web Flow, which can be used with Spring MVC, Struts 1 and 2 and JSF, can be used to take responsibility for the navigation and state management of a web application, allowing the flow to be rebuilt without restarting the server.
You can now use Spring IDE 2.0 to make a change to your navigation logic graphically (by drag-n- drop) and just see those changes take affect, again with no container restart. You don't even have to save your flow definition (the tool does it for you).
Struts 2 allows actions to be reloaded if they have changed. Patrick Lightbody cautions:
Ultimately the problem is that the chain of objects (ie: stateful action -> stateless spring services) gets so complicated that it becomes difficult to know what can successfully reload and what can't.
Although Tapestry 4 supported reloading of the HTML templates and page properties in a development mode, Tapestry 5 is adding extensive support for live class and template reloading.
As with the other frameworks, there are limitations:
- Auto-reload is not currently supported for resources in JAR files.
- Since the reloading uses classloaders, this can result in ClassCastExceptions when communicating with classes that haven't been reloaded.
- The potential for memory leaks if you retain references to classes that have been reloaded.
Wicket supports it as well
Now, finding ways to reduce that startup time is certainly an avenue for discussion, but in the meantime, it makes any reload capabilities somewhat appealing.
like Jetty, but better
Grails takes it one step further with Groovy's dynamic classloading by being able to reload Spring-loaded beans and domain classes that typically would require a server restart. Top notch productivity for me.
Slowing down the development process??!
But the result I have observed is that developers tend to implement too much before redeploying, then all a sudden the application doesn't behave as expected and they switch to the debugger. And there is were most of their time gets waisted...
So since Debugging sucks, Testing rocks, maybe Redeploys sucks as much and auto-reloads rocks even more for teams with junior members on board!
This breaks the developer focus and they try to defer restarting till they have made any major change. We came up with a custom jsp which would load configuration files for specific framework and let the developer continue the work without restarting (in few case restart were required).
And more the developer tries to defer restarting more are the chances of configuration error creeping in. So if reloading is provided as a inbuilt support in the framework that would be great.
One more thing to make use of is the exploded directory mode of deployment provided by most app/web servers. I have seen teams using the process of making an ear/war in there devlopemnt process also. If they take advantage of exploded directory way of deployment then it would greatly reduce the time taken for restarting+deployment
Thanks by the way, for the comments from RIFE, Wicket. While I hope you can all understand the challenge of trying to cover all Java web frameworks, I'm more than happy for the readers to get the information about the frameworks in which they are interested.
Sure. There's quite a few out there :)
Russ Danner May 03, 2015