MVC is a great pattern that provides nice abstraction and allows for an easy way to divide tasks amongst a team. Driving site navigation, externalizing connection info, messages and other properties is a great idea and allows for changes to a site that doesn't require recompilation of binaries.
Coupling the above with Tomcat and the ability to hot deploy makes for a great agile team. Things can work in a Continuous Integration/Continous Deployment model. Drop the files in, tell Tomcat to reload and life is good.
Well, almost.
Unfortunately, if you've utilized hot deploy, you find pretty quickly that there are a number of strange OutOfMemoryError exceptions in the logs. They are difficult to reproduce. Something is just not right ...
As I learned last week at the SV Web JUG meeting entitled "Is Instant Redeployment Really Possible", there are a number of reasons that hot deploy doesn't really work and the solutions to making it work aren't easy to accomplish.
Through the use of numerous code examples (and a few Starbucks gift cards), the meeting's guest speaker Sang Shin explained in detail why hot deploy is an idea not ready for primetime.
If your code has statics or singletons (and what code doesn't), the references to these objects are not neatly handled. Enough redploys and boom, you are out of memory. Essentially, the class loader holds a reference to each of the classes it has loaded and any class that can't be unloaded cleanly causes a memory leak.
It turns out to be that simple really - without purchasing one of the various commerical products that purpotedly handle the reference issue (which they do by creating an individual class loader for each and every class, property file, etc) you're hosed.
Not exactly the promise of hot deploy. Which is why I always have n + 1 servers running behind mod_jk