This post originated from an RSS feed registered with Java Buzz by Norman Richards. Original Post: The trouble with Servlets Feed Title: Orb [norman richards] Feed URL: http://members.capmac.org/~orb/blog.cgi/tech/java?flav=rss Feed Description: Monkey number 312,978,199 Latest Java Buzz Posts Latest Java Buzz Posts by Norman Richards Latest Posts From Orb [norman richards]

I often scratch my head and wonder what went wrong with servlets. The grand aspiration to have a generic servlet API capable of processing many different protocols never seemed to pan out. For all practical purposes Servlet == HttpServlet, end of story. I've always thought the servlet spec would be all that much better if we could just get rid of that layer and just have a simple HTTP-centric servlet API.

So, what do people who understand servlets even better than I do think? Well, not surprisingly, at least one of thinks servlets must die. Greg seems to agree that servlets shouldn't be abstracted to handle arbitrary protocols, but his reasoning is that they shouldn't be concerned with any specific protocols.

His idea is Contentlets, which are concerned only with taking consumming or creating data without regard for the protocol. No headers, no cookies, no content-length. His reasoning is compelling. I certainly don't like it when I see HTTP artefacts pop up in JSPs and I'd prefer not to have to consider them at the servlet level either. I honestly hadn't considered protocol independence a viable option though, as the current spec seemed proof enough that it just wasn't possible. I'm not really sure it is possible, but I'd like to see an attempt at it.