tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Date Wed, 13 Mar 2002 23:52:37 GMT
+1 for all, with an expansion on the last point.

Currently, Tomcat components all use the internal Logger APIs for logging
both container event and error messages, as well as those from the web
applications that are being run (i.e. calls to ServletContext.log()).
What would people think of migrating the container components of the HEAD
branch to use commons-logging, as well as having Coyote do that?

The most interesting technical part of this is that multiple instances of
many of the components (such as StandardContext) are used in a pretty much
autonomous manner, and you might want to have different logging levels for
different instances.  I think we can can deal with this by creating naming
of the underlying loggers, but wanted to gauge opinions before putting
together a proposal for that.

Craig


On Tue, 12 Mar 2002, Remy Maucherat wrote:

> Date: Tue, 12 Mar 2002 18:30:23 -0800
> From: Remy Maucherat <remm@apache.org>
> Reply-To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> To: tomcat-dev@jakarta.apache.org
> 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
> [ ] +0
> [ ] -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>
> [ ] +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>
> [ ] +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>
> [ ] +1
> [ ] +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>
> [ ] +1
> [ ] +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