Bill Barker wrote: > > ----- Original Message ----- > From: "Remy Maucherat" <[EMAIL PROTECTED]> > To: "Tomcat Developers List" <[EMAIL PROTECTED]> > Sent: Sunday, October 20, 2002 12:04 AM > Subject: Re: Bug 13658 > > >> 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. > > Right (and if I didn't have to support the 1.1.x community I'd agree). > Until Henri/Costin/Larry offer their opinions on supporting Coyote with > 3.3 for Java2 only, I'll have to (reluctantly) -1 using a HashMap in > o.a.c.Request.
I think it is perfectly fine for Coyote to require Java2. HashMap is available in GCJ/Kaffe and AFAIK in J2ME ( one of the profiles). I'll double check the last part. I would also +1 removing the JDK1.1 requirement for an eventual tomcat3.4. It's important to not confuse cause and effect - the 1.1 requirement is just a way to achieve the 'run anywhere' goal. At this moment Kaffe and GCJ support the collection and JNDI features - and they cover almost any platform/OS I ever heard of. If anyone can find an OS/platform that has a JDK1.1 but is not supported by kaffe/gcj - then we still have tomcat3.3 that can be used to provide servlet/jsp support for that platform. ( as any requirement - the 1.1 is set and removed by a majority vote, so if Larry would propose taking all the current fixes, plus coyote and have a release - he can include a proposal to drop 1.1 and the majority can decide ) -- Costin -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
