Debug deep dive into doDispatch() in Spring MVC

I’ve been stuck at home with sick kids so I just decided to take a debugging deep dive into the doDispatch() method of Spring MVC’s dispatcher servlet (DispatchServlet, the so-called “front controller“). Since this is my blog and I get to write whatever I want no matter how trivial, I thought I’d share two impressions, each of which are informed by a lack of sleep.

One impression: is Spring’s strength also its weakness?

I think of Spring as coming of age in era of enterprise Java when many competing frameworks were trying to be all things to all people. Spring beat J2EE in some early battles because it successfully appealed to all audiences while not imposing too much heavyweight configuration for most enterprise developers, which probably comes as a surprise to new today’s new developers. These days, developers are either annoyed or intimidated by its flexibility.

Its flexibility remains awesome, however. As an application developer, you can customize a HandlerMapping object, HandlerAdapter, HandlerExceptionResolver, ViewResolver, LocaleResolver, LocaleContextResolver, ThemeResolver, MultipartResolver, and a FlashMapManager. Just take a look at the DispatchServlet itself. It invokes the strategy pattern to use stategy objects on nine major configuration options:

Some of this annoyance and intimidation (and of course, I get both annoyed and intimidated too) comes from Spring’s impenetrable naming scheme. In its pursuit of being all things to all web developers, something like HandlerAdapter is so vague that it’s meaningless the first time you see it. And that’s easy compared to something like DelegatingFilterProxy or SerlvetInvocableHandlerMethod (which is a class, BTW). Spring has precise, but intricate and opaque (to the average developer) naming conventions.

So I guess my point on this impression is that I wish there was something like Spring Lite MVC that didn’t make me think about all these configuration options; I’m thinking of a light implementation that simply let me write some @RequestMapping decorated classes and some JSPs and call it a day. If I want to go further, I will.

Maybe Spring Boot will cure my worries, but is it too “opinionated” to build a simple MVC-CRUD-based web app without learning what the Spring folks’ “opinion” is?

Second impression: is Spring’s flexibility leaving optimization on the table?

Obviously, flexibility implies (requires?) a performance trade off. And if you’ve worked with Spring MVC, you know that a big part of its power is its ability to resolve a web request to @RequestMapping annotations you’ve used to decorate your controllers–without having to write XML. What you might not realize is (a) how deep in the stack trace you are and (b) that Spring MVC performs as if it’s the first time it’s ever seen your application for every single request. The first problem comes from Spring’s verbosity and their designers’ OO elegance. I’ll defer that issue to them.

It seems to me that the second issue could be solved with a little real world caching though. In mapping a simple request, say to “/” from a web browser, Spring MVC goes through a fairly tortured and exhaustive reflection-informed search of all annotations of all your classes for the right @RequestMapping mapping to a given request — every time! While that might only be a few dozen or a few hundred loops in any given Spring MVC solution, it still seems wasteful to me. Wouldn’t a simple @Cacheable annotation fix this — at least in part? Of course, if I’ve overlooked something and I’m wrong on this point, please let me know!

Leave a Reply

Your email address will not be published. Required fields are marked *