----- Original Message ----- From: "Peter M. Goldstein" <[EMAIL PROTECTED]> > > -1. > > Interferes with current short term plans still under discussion. >
I assume you are refering to the 'resettable, time-guarded' proposal. I agree that it is a good idea to have a lighter weight abstraction, but that should not prevent replacing a current broken implementation (not abstraction) esp. as it has already been tested and does not exhibit the leak. Sure, can hold off... > > Fails to address the already stated logging/validation concerns that > should be localized in the server class, as per my earlier post. How is the logging/validation any worse ? It seems that these are fine. There is nothing preventing the Params constructor to more validation if need be. Logging can be in one log file per protocol or one log file per server. This is controlled by separate logging config file. > > Exposes member variables directly, rather than by 'getter' methods. Isn't a final variable in a package scoped immutable object better than calling n getters ? You may notice that this addresses a larger set of instance variables more easily. n getter would make handlers more heavyweight(orig. concern) and may end up being a sizable chunk of code, thus distracting from the main methods. It is also easier to see the diffs and exact optimization made. All it involves is - replace instance variables e.g. timeout with params.timeout. There is one Params object for n handlers and it is passed into the handler constructor. To me refactoring for the optimization described seems like applying more changes and pulling in more code than need be. Harmeet -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
