Mark Brouwer wrote:
Rick Moynihan wrote:
I'm not sure about the time commitments I'd be able to make to River,
but I do have some ideas about specific improvements I'd like to see.
Particularly with the management classes, e.g.
ServiceDiscoveryManager, JoinManager, LookupDiscoveryManager etc.
>
Briefly, my main issue with these classes (and I guess other parts of
Jini) is that code which uses these classes is hard to unit test
because they don't have interfaces. I feel things would be MUCH
easier if these classes implemented an interface that would allow
developers to easily create mock implementations for unit tests etc...
Good!
I agree with you that it would be nice if some of these classes had
their contract specified by an interface and not only for the reason
you stated. As an example I had to develop proprietary interfaces to
capture some of the behavior for which the implementation is provided by
a container. JoinManager and ServiceDiscoveryManager couldn't be used
directly as they expose methods that gives a client control over things
the container is in control.
Yes, we've experienced similar things. In the case you describe I guess
it would be possible to subclass SDM/JM and then override and finalize
the methods you don't want to be called. Obviously though this isn't
ideal as you'd be cluttering the framework users API with calls they
can't use.
LookupDiscoveryManager I don't know though as that one has most of its
contract already specified by DiscoveryGroupManagement,
DiscoveryLocatorManagement and DiscoveryManagement. Anything missing there?
Yes, you're right about LookupDiscoveryManager. I should have actually
checked before sending the message to the group rather than going from
memory. I did however experience a slightly different problem with
LookupDiscoveryManager. Essentially, here I was happy with the combined
class responsibilities of all 3 interfaces. And I wanted to inject a
LookupDiscoveryManager into my classes as I didn't need require the
level of granularity provided. From my point of view it would have been
better if there was a LookupDiscoveryManager interface that extended the
3 interfaces, and was implemented by LookupDiscoveryManager(Impl). It's
a minor point, but from my recollection it did cause some headaches.
This has come up during the Davis project (2002) and although IIRC Gregg
Wonderly and I saw value in standardizing interfaces too versus only a
concrete implementation such as SDM I believe not everybody was that
convinced. But with the latest trend of dependency injection maybe
he/they became a convert ...
I think you've nailed the issue with the comments about dependency
injection. As that is exactly the model we were adopting and I guess
trying to squeeze Jini into. It can be done, but it's more work than it
should/could be.
Also has it been decided yet whether/when River will offer its own
(Jini)-starter-kit?
This has not been discussed AFAIK.
--
Rick Moynihan
Software Engineer
Calico Jack LTD
http://www.calicojack.co.uk/
