Lean Servlet Application Manifesto (work in progress)

Lean Servlet Applications:

1. Are highly modular.
2. Have a source hierarchy that is easy to understand and navigate.
3. Are packaged by functionality not by layer.
4. Have the minimum number of third party dependencies.
5. Are built directly on top of the Servlet API. For instance, they implement their own Servlets and do not rely on a Controller Servlet to handle all incoming requests, or any intermediate Filters to wrap or preprocess the Request.
6. Are designed to make it fast to build out more functionality (even things that had never been previously envisaged)
7. Behave predictably and fail loudly.
8. Are fast to build and deploy, and perform well.
9. Are not obsessed with being REST-ful, but like to keep their URLs logical and readable. They do not abuse the HTTP GET method.
10. Make the most of AJAX for a great user experience, but are not single-page Javascript applications.

Rules for developing Lean Servlet Applications:

1. All HTML must be generated from JSPs (or other templates). This means Servlets are not used to output HTML directly to the client, and no JSP tags are used to output HTML. Adding dynamically to the HTML DOM by JavaScript code is also kept to an absolute minimum, other than inserting pre-rendered HTML generated by a JSP.
2. No pages in the application link directly to JSPs, always to a Servlet which forwards to the JSP.
3. All application-wide Filters and Servlets such as error handlers are defined explicitly in web.xml.
4. Business/functional Servlets are not defined in web.xml but are mapped using Servlet 3.0 annotations.
5. Any shared or generally useful jar dependencies should be moved to the container's lib directory in order to keep the application WAR files as lightweight as possible. If this is too difficult to manage with Maven (or other prescriptive build tool), then don't use it.
6. Exceptions should be handled by the container, not by each individual Servlet.
7. The WebContent directory should be organised by functionality, so each module has its own directory with all its web resources and jsps. The top level should contain application-wide jsps and shared web resources. No separate folders for style sheets, images or JavaScript source files.