You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by kevin seguin <se...@motive.com> on 2001/06/25 00:06:35 UTC

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java

costin@apache.org wrote:
> 
> costin      01/06/24 14:17:13
> 
>   Modified:    jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java
>   Log:
>   Fixes for the code move.
> 
>   One big missing chunk is the adapter between o.a.ajp.AjpRequest and
>   tomcat33 request ( similar with the one for tomcat4 ).
>   I'm working on this.
> 

hey costin,  one of the things i've been planning on doing is changing
o.a.ajp.AjpRequest to make use of o.a.coyote.Request.  basically, wrap
Request in AjpRequest.  does this conflict with your plans?

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java

Posted by kevin seguin <se...@motive.com>.
kevin seguin wrote:
> 
> costin@apache.org wrote:
> >
> > costin      01/06/24 14:17:13
> >
> >   Modified:    jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java
> >   Log:
> >   Fixes for the code move.
> >
> >   One big missing chunk is the adapter between o.a.ajp.AjpRequest and
> >   tomcat33 request ( similar with the one for tomcat4 ).
> >   I'm working on this.
> >
> 
> hey costin,  one of the things i've been planning on doing is changing
> o.a.ajp.AjpRequest to make use of o.a.coyote.Request.  basically, wrap
> Request in AjpRequest.  does this conflict with your plans?

actually, i take that back.  i don't think i'm going to do that yet...
AjpRequest will stay as is for now (unless someone else has grander
plans :))

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33Ajp14Interceptor.java

Posted by kevin seguin <se...@motive.com>.
cmanolache@yahoo.com wrote:
> 
> On Sun, 24 Jun 2001, kevin seguin wrote:
> 
> > hey costin,  one of the things i've been planning on doing is changing
> > o.a.ajp.AjpRequest to make use of o.a.coyote.Request.  basically, wrap
> > Request in AjpRequest.  does this conflict with your plans?
> 
> Yes, a bit, as I'm going to wrap AjpRequest in a tomcat33 Request.
> 
> Object wrapping an object wrapping an object is not that clean.
> 
> Can we just use a single base request, say "BaseRequest", have it in
> util/ ( which is shared by everything ), and then just wrap it in your
> tomcat4 Request and in the tomcat33 Request ?
> 
> If we're going to do that, I would apreciate few method name changes,
> so I can use it as a base class for core.Request. If not - I can still
> wrap it.
> 

i saw your checkin comment regarding BaseRequest.  i have no problem
with moving AjpRequest to org.apache.util.http.BaseRequest.  let's not
make it final, though, so it can be extended.  you want to do that while
you're making other changes?

> The reason I prefer
>   foo()
> instead of
>   MessageBytes getFoo()
> 
> is that the second is associated with the get/set pattern ( when in fact
> it's you need to change the modifiable result ).
> 
> I'm ok with using it, but at least please name the private fields with
> other names ( like fooMB or _foo or something else ).
> 

that's all cool with me :)

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java

Posted by cm...@yahoo.com.
On Sun, 24 Jun 2001, kevin seguin wrote:

> hey costin,  one of the things i've been planning on doing is changing
> o.a.ajp.AjpRequest to make use of o.a.coyote.Request.  basically, wrap
> Request in AjpRequest.  does this conflict with your plans?

Yes, a bit, as I'm going to wrap AjpRequest in a tomcat33 Request. 

Object wrapping an object wrapping an object is not that clean.

Can we just use a single base request, say "BaseRequest", have it in
util/ ( which is shared by everything ), and then just wrap it in your
tomcat4 Request and in the tomcat33 Request ?

If we're going to do that, I would apreciate few method name changes,
so I can use it as a base class for core.Request. If not - I can still 
wrap it.

The reason I prefer
  foo()
instead of
  MessageBytes getFoo()  

is that the second is associated with the get/set pattern ( when in fact
it's you need to change the modifiable result ).

I'm ok with using it, but at least please name the private fields with
other names ( like fooMB or _foo or something else ).

Costin