TC 3.3 >= m3 Request.setRequestUri

[Keith Wannamaker <Ke...@Wannamaker.org>]

When the String -> MessageByte change was made 
to Request (rev 1.70), setRequestUri was tossed.
We were using that in a custom inteceptor to 
do some simplistic URL rewriting.

I can't tell from the logs or archives if it was
replaced?  Does anyone have a problem with me
adding a messagebytes version back?

Keith

RE: TC 3.3 >= m3 Request.setRequestUri

[cm...@yahoo.com]

On Wed, 8 Aug 2001, Keith Wannamaker wrote:

> Hi Costin,
>
> Oh, no, not at all, I understand now.
>
> However, what do you think about keeping the old String
> methods for compatibility with 3.2 interceptors?
> Something like:

:-)

All I can think at this moment is "how stupid I was
when I did the changes".


To my defense - the reason I removed the get/set was to
make sure the code is using the new API and to quickly
find the places where string-based methods were used
and replace them with more efficient MessageBytes methods.


If you have the changes in your workspace - please commit them,
it's not going to affect any existing functionality and
will simplify a lot porting 3.2 modules to 3.3.


Costin

RE: TC 3.3 >= m3 Request.setRequestUri

[Keith Wannamaker <Ke...@Wannamaker.org>]

| -----Original Message-----
| From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
| Sent: Wednesday, August 08, 2001 11:16 AM
| To: tomcat-dev@jakarta.apache.org
| Subject: Re: TC 3.3 >= m3 Request.setRequestUri
| 
| 
| Hi Keith,
| 
| After String->MessageByte, instead of storing the request
| info as String, with getFoo/setFoo methods, we use
| a MessageBytes - which is a modifiable object.
| 
| I don't see the point of replacing the field itself, but of
| course we can do that if you really need it.
| 
| Costin

Hi Costin,

Oh, no, not at all, I understand now.

However, what do you think about keeping the old String
methods for compatibility with 3.2 interceptors?  
Something like:

--- Request.java	2001/08/06 15:45:25	1.106
+++ Request.java	2001/08/08 15:40:07
@@ -309,9 +309,29 @@
     public MessageBytes method() {
 	return methodMB;
     }

+    /** @deprecated After Tomcat 3.2, use {@link #method()} instead */
+    public String getMethod() {
+	return methodMB.toString();
+    }
+
+    /** @deprecated After Tomcat 3.2, use {@link #method()} instead */
+    public void setMethod(String method) {
+	methodMB.setString(method);
+    }
+
     public MessageBytes requestURI() {
 	return uriMB;
+    }
+
+    /** @deprecated After Tomcat 3.2, use {@link #requestURI()} instead */
+    public String getRequestURI() {
+	return uriMB.toString();
+    }
+
+    /** @deprecated After Tomcat 3.2, use {@link #requestURI()} instead */
+    public void setRequestURI(String r) {
+	uriMB.setString(r);
     }
 
     public MessageBytes unparsedURI() {


Keith

Re: TC 3.3 >= m3 Request.setRequestUri

[cm...@yahoo.com]

Hi Keith,

After String->MessageByte, instead of storing the request
info as String, with getFoo/setFoo methods, we use
a MessageBytes - which is a modifiable object.

The equivalent of getFoo is now to get the MessageBytes and
call toString(), and the equivalent of setFoo is setString()
on the message bytes.

Of course, the main differences are that with message bytes we can
avoid the conversion to String ( or at least delay it until
we have the encoding ), performance, etc.

But you can do setRequestUri using the MessageByte.setString(),
it's a modifiable string.

I don't see the point of replacing the field itself, but of
course we can do that if you really need it.

Costin



On Wed, 8 Aug 2001, Keith Wannamaker wrote:

> When the String -> MessageByte change was made
> to Request (rev 1.70), setRequestUri was tossed.
> We were using that in a custom inteceptor to
> do some simplistic URL rewriting.
>
> I can't tell from the logs or archives if it was
> replaced?  Does anyone have a problem with me
> adding a messagebytes version back?
>
> Keith
>