RE: get rid of URLRewriter???

Very good.  I agree with your assessment.  Leaving it in place but making 
the default "true" instead of "false" and modifying it as I stated below is 
the right first step.  Consider it done.

Jake

At 10:22 PM 5/7/2003 -0400, you wrote:
>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
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda