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
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.