Java Web Frameworks Increase Support for Auto-Reload

by Geoffrey Wiseman on Apr 25, 2007 |

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

Related Editorial

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

Impact of Java EE Frameworks on the Structural Quality of Applications

Cluster-Wide Caching & Scaling for the Cloud - A Look Inside Resin 4.0

ICEmobile in a Minute - The Easiest Way to Mobilize Your Enterprise Apps

The Rise of the Composite API Platform, a ‘Best-of-Breed’ API Management Solution

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

RIFE by Geert Bevin Posted

Re: RIFE by Geoffrey Wiseman Posted

Re: RIFE by Eelco Hillenius Posted

Wicket supports it as well by Eelco Hillenius Posted

Grails by Kong Fanbin Posted

Impact by Kit Davies Posted

Re: Impact by Jesse Kuhnert Posted

Re: Impact by Geoffrey Wiseman Posted

like Jetty, but better by Thom Nichols Posted

Slowing down the development process??! by Alexander Snaps Posted

Reloading+exploded directory by Chetan Mehrotra Posted

RIFE by Geert Bevin

Hmm, well RIFE has been doing auto-reload, auto-compile and auto-reconfig since day one, ie. 6 years already.

Wicket supports it as well by Eelco Hillenius

Wicket supports auto reloading through a special filter (ReloadingWicketFilter). Limitations are stated in the JavaDocs.

Grails by Kong Fanbin

Grails supports this feature, and I found it is very useful for developer

Impact by Kit Davies

How great really is the impact of not having auto-reloading? I suspect it is more about the interruption to the thought flow than the actual time involved. IME, the impact is proportional to the number of steps required to redeploy. Hence auto-reload has zero impact but (as the examples above illustrate) not all frameworks support it, some only partially and all no doubt are more complex as a result. The alternative is to use a tool like Ant or Maven. Here the impact is restricted to a single step of invoking a target via a script or IDE plugin. Is this really too much?

Kit

Re: Impact by Jesse Kuhnert

I think one of the reasons why autoreload of the application is not always ideal is because you are re-starting your entire application. This can vary between taking a few seconds and sometimes up to a couple minutes depending on how large your application is and the physical limitations of the computer you are doing this on... Ie it's dead / static software. Not very compelling for people in the dynamic language camp.

Re: Impact by Geoffrey Wiseman

Exactly -- on one of the applications I work on, the application startup takes over 30 seconds, so when you need to make a series of minor changes, this can be a very frustrating thing, waiting for the server to come back up just to check the change you made.

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 by Thom Nichols

This is why I used Jetty when I did JSP development -- Eclipse's incremental compile + Jetty's auto-reload of JSPs meant that most stateless code would be auto-reloaded.

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??! by Alexander Snaps

I have come to notice something else than redeploys "just" slowing down the development process, which is far more armful: it doesn't promote agile development in the sense where, especially junior developers, tend to test less often. Of course we all have our code base covered at 99% by thoughtful tests, so this is almost no problem for most of us! The others can keep on reading ;)
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!

Re: RIFE by Geoffrey Wiseman

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.

Reloading+exploded directory by Chetan Mehrotra

Reloading of configuration files is a necessary feature. In our application we were using Struts+Spring+Hibernate. So if any minor change is done in files required by these frameworks then one has to wait for a minute to get the app running again.
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

Re: RIFE by Eelco Hillenius

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 :)