We needed a secure, lightweight embedded (in existing daemons) web framework that can leverage all the security configurations in hadoop-commons HttpServer. Most web frameworks assumes standalone webapps and want to dictate things like directory layout and configurations etc. Major portion existing MVC frameworks is devoted to some ORM layers that we don't need.
The main goals for the framework is security and ease of development (IDE refactor friendly, esp. for typical Hadoop developers who're not professional web developers with tons of plugins installed) and testing (webapps code needs to be fully unit testable at controller and view level without booting up web servers). This preclude frameworks that require embed class names in some config files (properties or xml), which is arguably a pervasive java anti-pattern.
It's very easy to accidentally write insecure and thread-unsafe code in existing web frameworks. Anything that uses JSP as the view layer is insecure and thread-unsafe by default (cf.
HDFS-1758). In this framework, all views are statically checked by the java compiler and every piece of data is escaped by default. Thread-safety is simplified as controllers and views are request scoped by default.
Hamlet is a novel and superior view technology that has no counter parts in any existing framework/language in that it's IDE friendly (without having to install tons of plugins): it gives instant autocompletion, javadoc and compiler feedback, showing the current tag stack (see attached IDE screen-shots), making it practically impossible to write invalid html (4.01 strict. In contrast, most frameworks don't even generate valid html in their tutorials, neither do all existing hadoop webapps.) The framework is precisely targeting devs who're not html experts who don't know about quirks mode and remember html spec (e.g., block elements is forbidden inside inline elements etc.) by heart. In the end, Hamlet is just a plain old java object builder (with creative use of generics) that every Java developer can pickup without having to learn any new (expression) language syntax that's needed for JSP etc. (Spring MVC typically use JSP as its view layer.)
Note, Hamlet.java only needs to be regenerated for people who want to hack on the framework (fixing bugs or support new html5 tags etc.) Webapps just use hamlet as a library. No xml, templates and config files to futz with. It just works by default.
After wrote all the new webapps with it, I'm happy to report that the yarn web framework achieved all the goals and then some. I have quite a few years startup production experience with Rails and I honestly prefer this framework despite it's in Java , mostly due to Hamlet, Guice and the precise IDE assisted refactor.
This framework might become a apache project by itself (like many other apache projects come to be), as it's emerging as a perfect lightweight embedded web framework for distributed systems. Note, this framework doesn't preclude a standalone web app using a different framework more suitable for standalone webapps, that pull data from different servers via (REST) APIs, in fact the framework can serve web APIs in a very simple way (comparable or simpler then typical JAX-RS implementations.)
See attachments for examples.