Bill Barker wrote:

----- Original Message -----
From: "Remy Maucherat"
To: "Tomcat Developers List"
Sent: Saturday, October 19, 2002 2:11 AM
Subject: Re: Bug 13658



>Bill Barker wrote:
>
>
>>Before I start performing major surgery on the TC4/5 connector, I
>>wanted to
>>check on what is the reason for having the attributes field in
>>CoyoteRequest
>>(instead of just delegating to the o.a.c.Request like the 3.3 Adapter
>>does).
>>
>>At the moment, the SSL request attributes are set on the o.a.c.Request
>>(because that's all that the Action knows about). This is Ok for
>>getAttribute, since it delegates when not found. But for
>>getAttributeNames,
>>it only uses the names known to the attributes field (so no SSL
>>attributes).
>>
>>My strong preference is to delegate always (cleaner, esp. for TC 5
>>that will
>>be able to access Coyote directly). But I can fix this particular bug
>>either way.
>
>I don't remember the reason. I probably chose not to delegate since
>there might not have been any attributes ariginally in the Coyote
>Request object.
>So it wasn't done because it wasn't there; I don't think there ever was
>a Good Reason (TM) for that.
>
>+1 to fix it.
>
>What's the surgery you want to do ?


Basically, remove the attributes field from CoyoteRequest, and delegate all
attribute related methods. The downside is that the CoyoteRequest uses a
HashMap, and the o.a.c.Request uses a Hashtable (non-sync/sync). For 3.3,
I'd really like to keep the Hashtable in the o.a.c.Request (so that Coyote
can be used with 3.3/J2ME). There is also the issue of the proposal to have
lazy evaluation in TC 5.
Sorry, I forgot about the hashtable problem. -1 then (or +1 to switch to more efficient collections). We could have two versions of the Request/Response classes, or use some preprocessing with Ant.

My work optimizing Tomcat is completely useless if it's to add many syncs.

Remy


--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>



Reply via email to