> 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.
You are confusing ABSTRACTION with IMPLEMENTATION. The ABSTRACTION of the
Watchdog interface is that client code has an opaque object with which to
interact using a small set of operations, e.g., start, stop, reset. As I've
mentioned, the interface hides the underlying implementation, which is where
decisions such as a second thread or shared thread implementation are made.
It can hide an adapter to the Avalon Scheduler interface, if one were to
insist on using the Scheduler.
The Watchdog is a just portable, lightweight interface. If someone wanted
to create a Block that provided Watchdog instances, they could.
> Handlers should not do this: foo = new SomeResetableTimeGuard();
You mean like in the current (CVS) code? Where it has:
final PeriodicTimeTrigger trigger = new PeriodicTimeTrigger(
timeout, -1 );
Thanks for bringing this up. Good news. Watchdog creation is no longer in
the Handler. Handlers are given a Watchdog. They are ignorant of the
implementation of that interface.
> ResettableTimeGuardedCommandMap was a suggestion
> to facilitate arriving at a good abstraction.
It is a completely different approach to handler implementation that
requires rewriting Handlers to use a command map. I had submitted code for
that over the summer, but I would not propose rewriting handlers for 2.1.
IF we rewrite the handlers for v3 to use a command map, changing how
handlers do timeout will be the least of our issues.
> Logging can be configured to ...
Logging support is provided to James by Avalon, and as you said, "Logging
facilities seem pretty flexible and good to me as it is."
> 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)
public interface POP3HandlerConfigurationData {
String getHelloName();
int getResetLength();
MailServer getMailServer();
UsersRepository getUsersRepository();
}
void setConfigurationData(POP3HandlerConfigurationData theData);
> Do you agree that the config optimization could be
> done in a more localized manner?
By localized, you mean you just want the change for configuration, and no
other code change? The changes I am aware of are:
- handler configuration
- this requires the server to prepare the service-wide
configuration.
- this permits object pooling of handlers and related objects.
- Watchdog interface
- Unlike the Scheduler interface, this interface hides
implementation details of timeout from the client
code, and supports arbitrary timeout mechanisms
transparently.
- Support for per-service (POP3, SMTP, ...) and global
connection limits.
> Why pull and duplicate code ?
It doesn't. Thread management has always been part of James, provided by an
Avalon thread manager. That thread manager still does its job. What DOES
open is the OPTION of having additional <thread-group> elements. And James
is now able to enforce connection limits per service.
AbstractJamesService does not "pull in thread management" or even use it.
What it does do is provide better control over thread pooling. It simply
finds out from the service configuration if a specific pool is to be used
for the service, gets either the specified pool or the default pool from the
thread manager service, and passes that onto the ConnectionManager. Threads
are still managed by the thread manager, and connections are still managed
(and dispatched on threads) by the connection manager.
> If there are issues in the Avalon Base Service
There is nothing wrong with Avalon's base service. But it does not model
the behavior common to Jame's services.
AbstractJamesService models behavior for James services. It provides a
shared implementation for derived classes, handling such common model
elements as bindaddress, port, enabled, useTLS, helloName, timeout, and
connection limits; behavior such as initialize and dispose; and exposes the
HandlerFactory interface.
--- Noel
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
