----- Original Message ----- From: "Noel J. Bergman" <[EMAIL PROTECTED]> Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service code
> > 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... > > But you did introduce an entirely new abstraction, the > ResettableTimeGuardedCommandMap. Or am I mixing proposals? It is the same proposal. I thought that the Watchdog as an abstraction lacked a few important things. These were the things that I thought were worth having : - Support m watchdog threads watching n handlers. - Publish 'resettable, time-guarded' as a pluggable service/block. Handlers should not do this: foo = new SomeResetableTimeGuard(); ResettableTimeGuardedCommandMap was a suggestion to facilitate arriving at a good abstraction. If we are moving to a new abstraction let us talk about what the right abstraction should be and not visit this again. > > > > > Fails to address the already stated logging/validation concerns that > > should be localized in the server class, as per my earlier post. > > > Logging can be in one log file per protocol or one log file per > > server. > > How are you defining the terms? By server do you mean James? Within James, > server == service == protocol. Server really has 3 meanings, it could be James, it could be a single protocol server instance or it could protocol server instances. I will attempt to be more unabiguous about nomenclature. Logging can be configured to - log pop3 listener on port 110 to a log file or - log pop3 and pop3 secure listener to the same or different file. or - log all serers to same file. Logging facilities seem pretty flexible and good to me as it is. > The bigger win in this change is that Peter adopted the single configuration > object that you, yourself, have promoted several times. He changed the > interface from calling n setters to calling a single method, passing an > interface to the immutable service-wide configuration data. This brings it > back closer to the Configure approach, but with an optimized config. > ... > Regardless of where it is passed, what you're suggesting is that it should > be: > serviceConfig.timeout instead of serviceConfig.getTimeout() > > As I said, I don't see a justification to abandon implementation hiding. Latter looks fine to me. I agree with your comments on information hiding. Is the configure object something like the one attached ? with POP3Handler having something like void setConfiguration(POP3HandlerConfig config) Regd this: > To me refactoring for the optimization described seems like applying more > changes and pulling in more code than need be. Do you agree that the config optimization could be done in a more localized manner ? I am not concerned about final variables vs. getters, but about pulling in code that may have little to do with this configuration passing optimization. Is there real need for AbstractService to pull in thread management etc. code into James ? Why pull and duplicate code ? If there are issues in the Avalon Base Service class, we should suggest patches to Avalon folks or deal with those issues separately. Harmeet
POP3HandlerConfig.java
Description: Binary data
-- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
