On Wed, 13 Mar 2002, GOMEZ Henri wrote: > +1, share code, share code. > > I'll be +1 to have it also in 3.3.2
'decodedRequest' is already there, commons-logging is trivial to add. The lifecycle of modules is also fine, the only problem is the ordering of modules - but so far it is under control, even if not perfect, and the hooks are in to allow an interceptor to fully control the ordering of each chain. Costin > >-----Original Message----- > >From: Remy Maucherat [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, March 13, 2002 3:30 AM > >To: [EMAIL PROTECTED] > >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:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
