All 1 entries tagged Development

View all 62 entries tagged Development on Warwick Blogs | View entries tagged Development at Technorati | There are no images tagged Development on this blog

September 06, 2005

Reducing turnaround time in web–app development

So, inspired by a brief daliance with Ruby On Rails, I started to think about how I could cut down the turnaround time for making changes to web apps written in Java. Now I start to think about it, it's really a pretty bad situation.

Take the new search application, for instance. If I make a change to a class, then it takes about 10 seconds to run the ant build, another 10 for the app. to deploy (basically, for the .war file to unpack), another 10 for the app. to start (spring config parsing and hibernate initialisation time), and another 3–4 seconds for the JSPs to compile. Same for a change to a JSP, a config file, or in fact more or less anything inside the .war. Add to that the fact that, since Spring+Hibernate+Jboss leaks memory on a redeploy, every 5 re-deploys needs a complete restart of the app server (about 1 minute). So for 10 changes that's 10 * 35 seconds + 2 * 1 minute – just about 8 minutes of thumb-twiddling. Not Good Enough.

Now, an awful lot of this is just un-necessary, and has arisen largely from inertia. So, step 1: get rid of JBoss, install Tomcat. Server restart time goes from 1 minute to about 10 seconds, and the server seems to leak much less memory – only needs a restart every 20 or so redeploys.

Step 1.1: Fiddle about for ages trying to work out how the frig you're supposed to get a datasource to work and register in JNDI. For future reference, this is how to do it with tomcat 5.5

– create a file in ${CATALINA_HOME}/conf/Catalina/localhost/ called {context}.xml

– make it look like this

<Context path="/search" docBase="${catalina.home}/webapps/search" 
        debug="5" reloadable="false" crossContext="true">
<Resource name="jdbc/searchDS" auth="Container" type="javax.sql.DataSource"

(n.b. this makes the datasource available at java:/comp/env/jdbc/searchDS)

Step 2: Tweak the project structure slightly so that within the project there's a deployable exploded war file. This isn't too hard, using eclipse's ability to specify multiple build directories – just make sure the class files etc are properly excluded from CVS. symlink the war directory into tomcat's webapps dir.

– I now have the ability to make changes to JSPs and the like and have them immediately update (+/- 5 seconds for recompilation) and we can redeploy the entire app. using the manager web application in about 10 seconds (no need to run ant or unpack the war file)

Step 3: Run tomcat in debug mode from within eclipse. You can set this up by hand, or use the Sysdeo tomcat plugin. I did the latter because it's less configuration effort. This allows you to use eclipse's HotSwap technology to make some kinds of changes to classes on the fly, without needing a redeploy. You still have to redeploy a change to a config file, or an incompatible class change (basically, adding new fields or non-private methods), but it cuts out about 30% of the redeploys. Incidentally, it's important to mark your context as reloadable="false" else tomcat will watch for class changes and re-deploy the whole app (10 seconds) every time it sees a change, rather than allowing it be be hotswapped ( which takes no discernable time)

So, the result is that my 10 changes are down from 8 minutes to about 1 minute – a worthwhile saving, I think, and it's probably already saved me one of the two hours it took to set up (mostly sorting out the wretched datasource).

The next challenge, though, is to take an application that's a bit more complicated than search (which is, after all, just a single web app. with half-a-dozen persistent classes). I'd really like to get the same kinds of benefit for Sitebuilder, because there's much more to gain there. A typical sitebuilder change requires a 2–3 minute ant build (inc. XDoclet re-generation of EJBs, checkstyle tests, and 200-odd unit tests) and deployment of 1 JMX SAR, 1 EJB JAR, and 1 WAR - about 1 minute from start to end, plus it requires an app server restart every few deploys. Sucky. As you can imagine, we rely a lot more on unit tests rather than redeploying the app constantly, but it's not an ideal solution. In the medium term, the in-progress sitebuilder rewrite will fix this (by ditching all the EJB crap), but in the short term we could save a lot of work by

– a smarter build that skipped unnecessary steps (like XDoclet regeneration when the sources haven't changed)
– deploying exploded packages, and fixing the classloader configs so that we can selectively redeploy just the .WAR, or just the .WAR + ejb-jar
– symlinking the exploded .WAR back into the project to allow JSP changes on-the-fly

update For my own future enlightenment, here's how to do the equivalent datasource stuff in tomcat 5.0.x

<Context path="/sitebuilder2" docBase="${catalina.home}/webapps/sitebuilder2"
        debug="5" reloadable="false" crossContext="true">
        <Resource name="jdbc/CmsDS" auth="Container" type="javax.sql.DataSource"/>
<ResourceParams name="jdbc/CmsDS">


Most recent entries


Search this blog

on twitter...


    RSS2.0 Atom
    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXXI