Can any one look at DefaultServlet.serveResource and honestly say they
have a good understanding of how this method actually works?
I'm counting 346 lines, 46 branches (some nested 7 levels deep), 9
return/exception points and mixed concerns including multiple resource
location strategies (war file, META-INF/resources, alternate doc
base..), directory listing / redirection handling, resource caching,
error reporting, range handling, content type resolution and finally
several seemingly different strategies for actually serving content.
Some 50 lines of the method seems to mix the concerns of looking up
resources from META-INF/resources in jars with creating and
configuring CacheEntry instances. (Why does this method even have to
do it's own resource lookup when we already have code for that in
ServletContext.getResource()? )
I think this method is in dire need of some refactoring. Don't get me
wrong: I do understand that code evolves over time as new features are
added. I'm not really pointing fingers at any one.
However, when trying to implement support for pluggable resource
loaders ([1], a JSR-340 proposal) I'm not really sure how to attack
this method :-) I might be able to squeeze my feature in, but who
knows what will pop out?
If anyone with more intimate knowledge of this code could take a look
at it, that would be very, very nice. We should try separating the
concerns of resource caching, resource location, error reporting and
serving of resources into smaller, less dependent methods. We should
also try to reuse ServletContext's getResource method where ever
possible, not duplicating the resource lookup logic.
Any takers?
Thanks,
Eirik.
[1]
http://java.net/jira/browse/SERVLET_SPEC-2