> I assume these are the interfaces. Please correct if this is not true.
Those are the interfaces Andrei and Peter developed. I am not aware of any
changes.
> How is WatchdogTarget associated with Watchdog?
The Watchdog was done by Andrei and Peter, but I'll give a shot at the
answers just to see how well I can understand the interface without their
further explanation.
The association is decoupled. There actually is no need for a tight
coupling between those interfaces at the highest level, and good reason to
keep it loosely coupled. For one thing, have you heard the concept
"narrowing of interface"? By NOT putting the WatchdogTarget in the
interface, it isolates code that just needs to reset the Watchdog from
knowing about Target related issues. However, the MutatableTargetWatchdog
interface does expose a setter (and perhaps should have a getter) for when
you do want to expose that interface. And there is another good reason,
which answers another of your questions (below).
In this case, Andrei and Peter have an implementation that which doesn't
need to be mutable. It works on behalf of a particular handler. The
constructor for that implementation takes an inner class object that
implements WatchdogTrigger, and can do what is necessary to interrupt the
handler (or whatever class is using the watchdog).
> - From the interface it appears there is a one to one mapping between a
> watched object and watchdog. This seems to impose an additional thread
per
> watched object. Could this lead to scalability issues.
This is wrong. That is not in the interface. I have told you already that
your shared thread code can be implemented as a Watchdog. Peter said that
he's already written that code, and will submit it after he finishes testing
it.
In Andrei's and Peter's IMPLEMENTATION of the Watchdog interface, they use
the dual-thread technique. This is generally considered the correct
approach, and is widely used, but even if you want or need something else,
the INTERFACE is completely neutral on that subject. When you instantiate
the Watchdog object, THAT is your direct handle to the Watchdog (rather than
a lookup key), but internally that object can be handed to a shared-thread
implementation. When you reset the watchdog, it takes care of how that
works. You deal with the Watchdog directly, and not the underlying manager.
> Is WatchDogTarget really needed ? Can Runnable act as WatchDog target?
Yes and no. If you feel that there is some method on Runnable that you want
to call, then you can create an ADAPTER object (that is what WatchdogTrigger
actually does) to call that method. The Watchdog interface is completely
neutral not only on the issue of a trigger implementation, but even on the
issue of a trigger interface. The trigger interface is imposed further down
in an interface hierarchy. If you needed some other notion of "target", you
can implement that, but the code that starts, stops and resets the Watchdog
remains unchanged. If you wanted to create some subtype of Watchdog that
worked directly with a Runnable, you could. But it isn't necessary, because
of the Adapter pattern.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
