hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: design Q #2: why the JSP pages?
Date Thu, 08 May 2008 17:18:45 GMT
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.
> 


Mime
View raw message