The general rule has been that urls that produce HTML are written in
JSP, and urls that generate data are written as servlets. I don't think
this has ever been explicitly discussed, it's just the way we've gone.
(Note that Hadoop's JSP's are compiled offline, so that we don't require
a java compiler at runtime, plus they're guaranteed to be free of JSP
parse errors and Java compilation errors.)
So this is not cast in stone nor the result of deep architectural
principles. If you think some of the JSPs would be clearer and simpler
as servlets, please submit patches. I love to see patches with more -'s
than +'s!
Doug
Steve Loughran wrote:
My other q is why are some of the servlets implemented as JSP pages,
when, if you look into them, they are pretty much inline GET handlers in
the servlet.
-This adds an step to the build process and requires exactly the same
Jasper run time at the far end
-Doesnt appear to benefit the internals of the jsp pages much
In particular, pages like dfshealth.jsp look fairly complex inside (but
not as complex as happy_axis.jsp, my contribution to axis's health
checking [1]), but with very little formatting (and the omission of the
cache-content pragmas) it would seem to be cleaner and simpler to move
them into pure servlets inline.
Or is there a future plan to do more with JSP -in which case the pages
just need to be brought up to date with the right hadoop links and proxy
caching disabled.
-steve
[1] happyaxis.jsp:
http://svn.apache.org/viewvc/webservices/axis/trunk/java/webapps/axis/happyaxis.jsp?view=markup
-designed to diagnose the absence of axis.jar, hence is fully self
contained
-sets 500 on an error.
-forgets to set the no-cache options; doesnt work through a proxy
properly.
