Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 67508 invoked from network); 13 Mar 2002 23:52:55 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 13 Mar 2002 23:52:55 -0000 Received: (qmail 2674 invoked by uid 97); 13 Mar 2002 23:52:55 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 2652 invoked by uid 97); 13 Mar 2002 23:52:55 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 2634 invoked from network); 13 Mar 2002 23:52:54 -0000 Date: Wed, 13 Mar 2002 15:52:37 -0800 (PST) From: "Craig R. McClanahan" To: Tomcat Developers List Subject: Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD In-Reply-To: <026201c1ca37$0835cc40$6501a8c0@apache.org> Message-ID: <20020313154907.A8934-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N +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 > Reply-To: Tomcat Developers List > 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). > > > [ ] +1 > [ ] +0 > [ ] -1: > > > > 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. > > > [ ] +1 > [ ] +0 > [ ] -1: > > > > 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. > > > [ ] +1 > [ ] +0 > [ ] -1: > > > > 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). > > > [ ] +1 > [ ] +0 > [ ] -1: > > > > 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. > > > [ ] +1 > [ ] +0 > [ ] -1: > > > > +1 for everything. Thanks for voting / commenting :) > > Remy > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: