One or two years ago I'd have said the same as some other guy has answered: Java + wicket. However, in the meantime I discovered something new, something awesome, which heavily blurs the distinction between web apps and rich clients: qooxdoo. Qooxdoo was a refreshing surprise in a long time for me. It allows you to do so many things client side that the server side doesn't matter that much anymore. It even provides readymade connection components to the server for various languages (PHP, Java etc.).
For the server side we developed a solution which we will probably settle on for many projects: qooxdoo's JsonRPC backend for Java, a custom servlet for file uploads, a custom servlet filter for authentication, all wired together via web.xml (and all being application-agnostic components), plus an ordinary spring application wired together via a spring XML context, including some additional but mostly ready made (i.e. not developed by us) components for logging, transaction management, connection pooling and the like. We use services (with the meaning Spring gives to the term) to answer to browser requests, and DAOs (as objects who know to read and write to the database, and abstract the database's relational structure to dumb objects with no logic passed to services). It is definitely not the quintessence of OO programming, but it is definitely manageable, even for complex data structures, very well unit-testable, and, more important, highly scalable and easy on the server, in terms of bandwidth, processor cycles and memory.
This app structure comes with a few bonuses - I'll explain two of them. Given the clear separation between client and server, you have to properly structure your app right from the beginning, or are forced to do so on the way, so anyway you end up with a clear separation of concerns. Given this requirement/effect, besides your architecture being much cleaner (than that of an app not forcing you to do such a separation) and staying this way even after many iterations, the app is much easier comprehensible, and new people can quickly become productive, without much effort - you essentially never have to rewrite, or can do so incrementally . Second, given that the client and the server talk via well defined and standard JSON-RPC requests (even the initial login can be such a request), your app is open for 3rd party integrations right out of the box, without any additional effort.
As for tooling, we use eclipse with a few additional plugins (maven, spring IDE, aptana, subclipse), maven as a build tool, Cruise Control for continuous integration, and Selenium IDE plus qooxdoo's Simulator extension for scripted testing. The development server is tomcat, with a mysql database. Since the persistence relies on simple, portable stored procedures, it is both fast and efficient (there's no faster way to call the database than stored procedures), and easily portable (although not as easy as using hibernate, but unfortunately hibernate has become a monster, IMO, and wrting its HBM files is no easier and probably not generating a database as efficient as a hand-crafted database with stored procedures).