RE: get rid of URLRewriter???

Hi Jake,

I think you are basically right, but its been a LONG time since we dealt
with this. Basically, the purpose of URLRewriting (it I remember correctly)
is to handle situations where the browser does not support cookies for
session mgmt...in that case you need to turn url rewriting on. The problem
was, Enhydra 3.x had a bug, which meant it wouldn't work. So we added the
variable and so that it could be configured on or off, and the default was
off.

> 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;
> }

I'm not opposed to removing them, but I do think we may want to be able to
turn the functionality off if we need to.

Now, I've checked with our production sites here, and none of them have it
turned on. SO...if we make the default be ON, and then remove the ability to
turn it off, then if there turns out to be a problem that might not be good.

SO...what I'd suggest for now is that we leave teh REWRITE_URLS in place,
but change the default to be true and to simplify it as you've given above.

That leaves us with all our options, and as soon as we confirm that
everything is nice and stable, then we could go ahead and yank it.

I don't think we need to worry about supporting Enhydra 3.x any longer
though...

That's my .02...
Christian

(Sorry its taken me so long to respond to this...thanks for your patience
;-)



----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Jacob Kjome
> Sent: Monday, May 05, 2003 12:07 PM
> To: [email protected]
> Subject: [Barracuda] 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
>
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda