get rid of URLRewriter???

I was just looking at Barracuda's URLRewriter and don't quite see the point 
of its existence other than getting around Enhydra 3.xx and early Tomcat 
3.1.x and 3.2.x bugs.  In addition, I think it is adding more logic than it 
needs to as it is simply duplicating what the response object already does.

Below is what URLRewriter.encodeURL does....

HttpSession session = req.getSession(false);
if (REWRITE_URLS && session!=null && !req.isRequestedSessionIdFromCookie()) {
     return resp.encodeURL(url);
} else {
     return url;
}

Let's look at this piece by piece....

1.  REWRITE_URLS - this tells us whether we even want url encoding and is 
merely a cover-up for the enhydra and early tomcat bugs I mentioned 
above.  I'm not sure how valid this is now.  I can pretty much guarantee 
that the current codebases of Tomcat 3.3.x, 4.x.x, and 5.x.x do URL 
rewriting correctly.  I cannot say for sure, but I would think that Enhydra 
5 has this working now.  Maybe we can get confirmation on this?  If this is 
not an issue anymore, I'm not sure this is needed at all?

2.  session!=null - see below, this is merely a precondition to do the 
check in #3 and I don't think it is necessary anyway since I'm quite 
positive that the request object checks for a null session and handles 
that, so we should be able to remove this altogether and just call #3 
without this check.

3.  !req.isRequestedSessionIdFromCookie() - this is duplicating logic that 
the response.encodeURL() already does so it seem to me that this is 
unnecessary as well.


So, #2 and #3 are, as far as I can tell, totally unnecessary.  The only 
reason for this classes existence is being able to globally set the 
REWRITE_URL's to control for bugs in early Enhydra and Tomcat versions and, 
to me, this is no longer a valid reason at this point anyway since pretty 
much all current versions of Tomcat (and probably Enhydra 5) no longer 
contain the bugs that cause the problems this was meant to solve.  At this 
point, the plankton.http.URLRewriter is no longer required.   The 
core.util.http.URLRewriter is arguably useful since it provides utility 
functions to encode a URL given a ViewContext.  However, all this really 
does is....

return URLRewriter.encodeURL(vc.getRequest(), vc.getResponse(), url);

why not then just do.....

vc.getResponse().encodeURL(url);

How simple is that?  Pretty darn, I'd say.

I think this is one of those cases where we drown ourselves in utility 
classes.  I don't see the necessity for these classes anymore other than 
backward compatibility for people using this class directly.  There is even 
a possibility that we might be introducing bugs the way we are doing the 
checking (no proof, just suggesting the possibility).  Either way, we are 
duplicating functionality of the servlet api and shouldn't be doing that.

I'm +1 to remove both classes.  Anyone else?  If not, the alternative would 
be to simply do....

if (REWRITE_URLS) {
     return resp.encodeURL(url);
} else {
     return url;
}

no need for the other checks.

Jake