Christopher K. St. John wrote: > Remy Maucherat wrote: > >>> - 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. >> > > > Maybe I'm just hung up on some of the wording, then. I'd > like to see specifically: > > - An item about coming up with a set of benchmarks and > performance goals as a priority. My BS alarms go off > when people discuss performance outside of an agreed > upon set of benchmarks (even if I know them to be > smart developers who probably have really done the > bencharks and profiling)
Lol. We could spent 3 years to agree on something. This is a complete waste of time. > - Details about how the existing Catalina JXM management > interfaces will be merged with Coyote JXM management > code. Or at least an acknowledgement that it's an issue. The beauty about JMX is that you don't have to merge anything. You just register the beans in a different domain in the server, and voila, it's all done. Then, either Catalina's admin webapp can decide to display these, or they can only be used internally. This is not the point of the proposal to decide that particual implementation detail. > - A listing of specific issues with Tomcat 4's current > implementation. for example, the startup code is opaque, > it's unclear what events get sent when, etc. The > important thing is that there's a specific list of > problems that need to be solved. I think I'm -1 on changing that. However, this is an issue with the Catalina design, and this proposal doesn't attempt to define any change in Catalina other than implementing the new specifications. The rest can be done in other proposals (although I'm likely to veto important changes which would break the API). > - And (I may be reaching here), Coyote is moved from being > "core" to being "the connector architecture". That's the opposite. Plus, it's an arbitrary naming convention. >>BTW, maybe you consider all that ugly, but I don't. I find >>the XML Mapper / Digester pretty cool >> > > > I really like the Digester. I was referring specifically > to how non-optional parts of the core implementation (like > ContextConfig) are added as listeners instead of being > called explicitly. They look like they should be pluggable, > but the way they're implemented right now, they're not. You have to be really careful about making gratuitous changes like that. I have no time to spend on this personally; if you want to experiment, go ahead and submit a proposal on that later. Again, this is an implementation detail (assuming it doesn't break the API). Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
