by Steven J. Owens (unless otherwise attributed)
"Those who cannot remember history are doomed to repeat it."
"Those who do not learn TCP/IP are doomed to reinvent it."
A lot of frameworks seem to spend a lot of time and energy reinventing the servlet API. I don't really think this is happening because they forgot (or didn't bother to learn) the servlet API in the first place. For one thing, some of the most popular frameworks are largely the brainchildren of folks who are involved in the JCP servlet specifications, like Craig McClanahan and Struts.
However, I do often find it annoying that most frameworks require you to redesign your application in terms of the framework, instead of providing a tool that works with the way the servlet API does things, and solves a specific problem in a friendly way.
Sometimes this is simply because there just plain isn't a way to do it in the servlet spec. One of the big design weaknesses of the servlet spec is that the organization structure of the site tends to get dispersed among many different links embedded in the rendered HTML. There is no way to radically revise this without coming up with your own scheme for controlling the organizational structure, instead of using servlet mappings. (The most common approach in the framework world seems to be using a single controller servlet, and having it determine the mapping by matching an HTTP parameter with a configuration file.)
However, to some degree it's the JSP question all over again. I think that there are more annoying problems to solve, and that they can be solved surgically, in a tool fashion. If you use tools to reduce complexity and clutter enough, maybe the remaining organization dispersal problem isn't such a headache.