Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Java Web Frameworks Increase Support for Auto-Reload

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.

Keith Donald adds this, about Spring IDE 2.0's support for Spring Web Flow:

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
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.

Tapestry 5
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.

Rate this Article