Christopher K. St. John wrote: > [EMAIL PROTECTED] wrote: > >>If you can clarify your concerns - do you disagree with Coyote >>entirely ( and why ), is it something missing that you want >>added or something that is there and you feel shouldn't ? >> > > > Fair enough. I think part of the problem is that one > of the primary goals of the proposal appears to be to > find common ground between the Tomcat 3 and Tomcat 4 > camps. I have the sneaking suspicion that the code should > be the primary concern. > > A straw-man proposal might help to clarify my worries. > (it's not a real proposal, I'm looking to be told what > my incorrect assumptions are) > > From the standpoint of supporting the 2.4 spec (totally > ignoring the 3/4 thing), it seems like this might make > more sense: > > - A represenative set of benchmarks is agreed upon, > in advance, and tests are run to determine what > Tomcat 4 performance is like now, where the > bottlenecks are (based on profiling, not intuition), > and performance goals are set for Tomcat 5. What > needs to be faster? Static file serving? HelloWorld? > JSP's? How much faster? Exactly? etc, etc.
I suggest you do them, and convince yourself. It is not my buisness trying to justify what should be evident just by reading the code. The Coyote adapters use lazy evaluations and GC efficient objects to achieve better performance. > - The most ugly bits of Tomcat 4 are listed, and a > subset of them is set aside to be fixed. I've chosen > the startup code and tomcat events/listeners as my > biggest concerns for this straw-man, but I'm sure > there are others. It's mainly the process of choosing > actual, concrete problems (instead of generalities) > that I think it important. The startup code (scripts, Bootstrap and Catalina classes) will still be present for compatibility. BTW, maybe you consider all that ugly, but I don't. I find the XML Mapper / Digester pretty cool when you really think about it, and would really hate to see them go away. -1. > - Tomcat 5 is Tomcat 4 with lots of cleanup work and > modifications for whatever the 2.4 spec comes up > with. There are no major architectural changes. OTOH, > the 2.4 spec could be bizarre, in which case all bets > are off :-) My proposal is not very different from that. > - Coyote is not part of Tomcat 5. Instead, Tomcat 5 > moves to having 2 (and only 2) connectors that are > single-purpose no-compromise performance demons: > > - A special-purpose HTTP connector built to take > full advantage of Tomcat 4, with a few layers > of abstraction as possible, using the existing > o.a.c.Connector API. This results in the smallest, > fasted code possible. > > - A special-purpose AJP connector. Again, single > purpose, build for Tomcat 5 only, using the > existing o.a.c.Connector API, and again,this > results in the least possible amount of code. -1. I did it already, it doesn't work. > - Other connectors can be implement in j-t-c as > needed, maybe as Coyote. Experiments like JNI, etc > shouldn't be a consideration for the core Tomcat 5 > design. There should probably also be some work > with the NIO api's non-blocking stuff, ala what > Greg Wilkins has done with Jetty, but again this > is non-core. I don't care about what you define as the core. If it has to be the servlet container implementation for you, then so be it. I personally define the core as exactly the Coyote API. - Jetty defines the core as the HTTP implementation. - You could write a NIO based HTTP connector for Coyote. - JK 2 with JNI is only experimental as the moment, and is not part of the core. It is a protocol handler which plugs into the core. The proposal is what we call the new core be a modified version of the Coyote API (package org.apache.coyote, not including any subpackages). Then, there's the servlet container running on top of it (Catalina), and the protocol handlers running below it (HTTP/1.1, AJP, JNI, hopefully WARP). Then, we proobably need some new loader code to startup the whole thing (that's hopefully going to be provided by commons-daemon). > - Tomcat 5 cleans up the current startup spaghetti > by going through each and every Tomcat event listener > and deciding if it needs to be made into a real, > explicitly called API. Listeners should be hooks > for extensions, making them them implement core > functionality makes for a tangled mass of pointers > and a very confusing startup sequence. Pretty much > everything but the management listeners need to go. > > After most of the listeners are removed, the set > of Tomcat events is rationalized and documented. > This is a big deal. This code is an undocumented > mess. Strong -1 for actually changing the Catalina API. Rewriting the modules yet again is the biggest mistake we can possibly make. > - There are places where the Standard* classes make > ugly assumptions about one another. This needs to > be examined on a case-by-case basis, and most of > the really ugly stuff needs to be removed, or the > assumptions need to be made into real method calls > in the top-level interfaces. At best, it's a small implementation detail. As long as it doesn't break the API too badly, I'm in favor of doing that, but we're not going to detail everything from that catagory in the proposal. Actually, this looks to me like things which could even go in 4.1.x. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
