tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Date Wed, 13 Mar 2002 07:20:57 GMT
Disclaimer:
A +1 vote below does not necessarily mean that I'm going to pledge ongoing
support to o.a.c.tomcat4 (although it is very well done, and I relied
heavily on it for developing o.a.c.tomcat3). However, I do plan to support
o.a.c and o.a.c.http11.
----- Original Message -----
From: "Remy Maucherat" <remm@apache.org>
To: <tomcat-dev@jakarta.apache.org>
Sent: Tuesday, March 12, 2002 6:30 PM
Subject: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD


> There are many ways to take advantage of Coyote in Tomcat 4, but I'd like
to
> start with some limited changes at first. Most of these proposed changes
are
> Coyote-related (hence the subject of the message), and all involve some
> refactoring / API additions.
>
> A) URI decoding refactoring. To avoid doing some URI decoding in many
places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding
occurs
> (which can lead to URI-based security attacks).
>
> <ballot>
> [ ] +1
> [X] +0 Already in the 3.3 code (and currently ignored in the 3.3 Adapter).
> [ ] -1:
>
> </ballot>
>
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> connector, which has many shortcoming (slow performance on output, HTTP
> handling limitations and extreme complexity). Initial tests results and
> benchmarks with Coyote are extremely positive so far.
>
> <ballot>
> [X] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> C) Add better lifecycle handling in the resources. A start method is
needed
> (which could be called 'allocate' to mirror the 'release' method), because
> it is currently not possible to restart a stopped context. In the 4.0
> branch, the patch introducing the 'release' method must either be
reverted,
> or these proposed changes must also be ported to 4.0.
> Thanks to Jean-Francois Clere for the report and debugging of this
problem.
>
> <ballot>
> [X] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> be used for any new connector development. To make this more obvious, I'd
> like to deprecate all classes in this package and subpackages. The
binaries
> will also be packaged in a separate JAR file (tentatively named
> catalina-legacy.jar). This package will continue to be maintained on a
case
> by case basis. The facades will not be deprecated, and two new helper
> objects will be introduced to handle the need for "fake" req/resp when
> requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> more details).
>
> <ballot>
> [X] +1  I couldn't ever find the "fake" req/resp for 4518 (ok, in 3.3
land, any class that ends in "Base" is an abstract class. ;-)
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> E) Use commons-logging in Coyote, by adding a get/setLogger on the
Processor
> interface. Otherwise, the processor has no way to cleanly handle logging.
> commons-logging is already used by other j-t-c components. At the moment,
> the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> needs to be improved. When I originally designed most of the base
> interfaces, commons-logging didn't exist yet, and I didn't feel like
adding
> yet another logging interface.
>
> <ballot>
> [X] +1 I'm guessing that Costin & Larry will have fits with this (TC 3.3
currently has no dependencies on outside packages).  However, my support is
only if it gets into o.a.c.Processor.   It shouldn't be a http11 only issue.
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> +1 for everything. Thanks for voting / commenting :)
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
<mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-dev-help@jakarta.apache.org>
>


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


Mime
View raw message