-1. Interferes with current short term plans still under discussion.
Fails to address the already stated logging/validation concerns that should be localized in the server class, as per my earlier post. Exposes member variables directly, rather than by 'getter' methods. While I don't object to a "Params" object per se, this implementation is not acceptable for these reasons. > Regd. service refactoring I had promised to send an alternate patch in, > but > had not done so. > > I hoping to not get into a long discussion on this one, as even the more > important > 'Interface for resettable, time-guarded, operations' issue has not been > resolved. I would have preferred to have a better scheduler implementation > in place till the 'resettable, time-guarded' proposal is resolved. > > This is an attempt to finish something I had promised to send earlier. My > main motivation is that we should not be refactoring existing stable code > and pulling in parts of Avalon unless we need to. If there are specific > issues in the way James is architected we should resolve exactly that. > In this patch I have broken the dependency between POP3Handler and > BaseConnectionHandler, but I think is better to keep the current > abstraction > as there is lot of commonality between protocol handlers. For instance > variables like Socket, Input Stream, Output Stream etc need not exist in > separate handlers. > > This is a complete working patch. > > Hope this discussion doesn't trigger another looong round. > Harmeet > > here is what the patch addressees: > ----- Original Message ----- > From: "Peter M. Goldstein" <[EMAIL PROTECTED]> > There were a number of very serious problems with the handler heavy > approach. > > First, there was the simple expense. Server objects are created once > per service, handler objects are created, fed through the lifecycle, and > destroyed multiple times a second. Thus it is advantageous to move as > much of the lifecycle expense into the server code. > > Second, there's a bizarre division of configuration information. -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
