"Craig R. McClanahan" wrote: > > +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?
1+ > > 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 <[EMAIL PROTECTED]> > > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > > 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]>
