Hani points out some problems with the Servlet spec that hit painfully close to home.
I’ll add a couple that I’ve run across:
The fact that Filters are only applied to the initial request and not subsequence child requests (RequestDispatchers) is insane. An example of such a need comes up every day, with the most recent being: we use Struts at Spoke (I know, I’m working on switching them to WebWork and Struts is crappy enough not provide any way to log (in a standard format) what JSPs an action forwards to. Now since Struts is probably never going to be good, I figured that at least if the Servlet Spec was decent (I can dream, can’t I?) then I could just use a LoggingFilter to do real performance analysis and logging. Imagine:
/dashboard.action 250ms - dashboard.jsp 180ms - panelX.jsp 80ms - panelY.jsp 100ms
Of course, WebWork supports this pretty easily Atlassian has released a profiling tool to do this for WebWork 1.3, I’ll add 2.0 support soon.
Another pain with the Servlet Spec is the oddness with JspWriter vs. PrintWriter vs. ServletOutputStream. I know, there are reasons for each one, but honestly, can’t everyone just get together and figure out one, simple way to write content to a response?
Also, what’s up with having multiple paths to get to places. Sure, helper methods are nice and all, but take for instance: ServletContext.getRequestDispatcher() vs. ServletRequest.getRequestDispatcher(). Yes, I know that ServletRequest has that method just to be helpful, but in reality it’s just annoying. In fact, I’d wish that ServletContext lost the method and it was only accessible through a request. When will anyone ever make a request dispatcher with no associated current request? The reason I hate that there are two ways to do this is because Struts chose to use the ServletContext approach, eliminating any chance of me finding a workaround for my logging woes described above. If at least they used ServletRequest instead I could wrap the request and intercept the neccessary calls for logging. Alas, I cannot.
In short: I blame the Servlet Spec followed closely by Craig McStruts. Now if only the rest of the world realized that Struts was horrible, rather than thinking it’s “the way to build webapps” (you have NO idea how many people in this community think Struts is the best thing since sliced bread — I generally just assume they are retarded.)
on Sep 25th, 2003 at 3:58 pm
AHMEN BROTHER!!!! Part of the reason why I am on this “crusade” of educating others on frameworks is so that they understand that there are other solutions out there for creating webapps and many of them are BETTER then the defacto standard of Struts.
on Sep 26th, 2003 at 4:00 am
Not all servlet containers apply filters only on the initial (”external”) request… Orion, for example, and OC4J by derivation, apply filters also on “internal” requests (i.e. generated by a RequestDispatcher).
This variation has got me up several times, because there are cases in which you want a filter applied only on the browser-generated request (i.e. filters on login) and cases in which you don’t.
on Sep 26th, 2003 at 6:03 am
If Web/X/Work is so great compared to Struts how about pointing us to the reasons why, or writing a detailed, point-by-point, blog entry about how Struts sucks compared specifically to Web/X/Work.
on Sep 27th, 2003 at 8:55 am
The filter stuff is clarified and fixed in Servlet 2.4. You can specify on entry only, on entry and includes, forwards, etc. Peace.