You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Rick Moynihan <ri...@calicojack.co.uk> on 2007/05/17 18:15:16 UTC
How to Contribute to River
Mark Brouwer wrote:
From Jini-Users:
> Rick Moynihan wrote:
>
>> Before posting I'd also taken a peek at the source for LookupCacheImpl
>> and ServiceDiscoveryManager. And you're not kidding about how many
>> details it takes of! We recently reimplemented/simplified some old code
>> that did not previously make use of these classes. And I'm glad we did,
>> though we did also need to build a layer above them to cache
>> LookupCaches across services running within the same VM.
>>
>> Thanks again for your response,
>
> Glad it was helpful,
>
> Given your intimate knowledge of the SDM now I think you should consider
> yourself a good candidate to help out improving it even further as part
> of River ;-)
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...
Also has it been decided yet whether/when River will offer its own
(Jini)-starter-kit?
--
Rick Moynihan
Software Engineer
Calico Jack LTD
http://www.calicojack.co.uk/
Re: How to Contribute to River
Posted by Jim Hurley <Ji...@Sun.COM>.
On May 17, 2007, at 12:15 PM, Rick Moynihan wrote:
> :
> Also has it been decided yet whether/when River will offer its own
> (Jini)-starter-kit?
Hi Rick-
The River project will obviously have releases -- we just haven't closed
on the name/form/or format yet. Thanks for the question, though... I
had
hoped to kick off a discussion on this, so I'll use this as a
catalyst to get
that going. I'll use a separate thread to focus it.
thanks -Jim
Re: How to Contribute to River
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
>> Well that would make it hard to have multiple implementations as part of
>> the same JAR file, test sets, etc.
>
> Start with an abstract class, and do all variants as subclasses of that?
While writing my posting I knew you were going to say this if you
couldn't resist to ignore me :-)
--
Mark
Re: How to Contribute to River
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
>> I wasn't suggesting subclassing, rather complete reimplementation.
>
> Well that would make it hard to have multiple implementations as part of
> the same JAR file, test sets, etc.
Start with an abstract class, and do all variants as subclasses of that?
- Bob
Re: How to Contribute to River
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
> Mark Brouwer wrote:
>> But my main argument against alternate implementations (by extension
>> that is),
>
> I wasn't suggesting subclassing, rather complete reimplementation.
Well that would make it hard to have multiple implementations as part of
the same JAR file, test sets, etc. Different implementations with the
exactly the name seems problamatic to manage for multiple reasons. Not
even talking about the lack of tool support for creating your mocks.
>> Interfaces gives an ultimate freedom and allow for minimal dependencies
>> and I don't see why we can't factor out some of the functionality of SDM
>> e.g. into an interface, do you Bob?
>
> Many things are possible, priority is the question.
Well that I consider a big leap forward :-) I agree with the priorities,
but I think it is worth an issue in JIRA (Rick?).
--
Mark
Re: How to Contribute to River
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> But my main argument against alternate implementations (by extension
> that is),
I wasn't suggesting subclassing, rather complete reimplementation.
> Interfaces gives an ultimate freedom and allow for minimal dependencies
> and I don't see why we can't factor out some of the functionality of SDM
> e.g. into an interface, do you Bob?
Many things are possible, priority is the question.
- Bob
Re: How to Contribute to River
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> Given the fact you mention tackling things that really are hard, can you
> give a hint about the things you are thinking about.
I don't have an agenda for River; I expect to largely be in a
review/advise/knowledge-transfer mode for the project.
- Bob
Re: How to Contribute to River
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
> Rick Moynihan wrote:
>> None of this stuff is particularly hard, and I don't mean to be picky,
>> as there are clearly ways around some of these issues. My problem is
>> only that these things could all be a bit easier.
>
> That's one of the things to wrestle with as we go forward, priority
> of making a bit easier things that aren't really particularly hard,
> vs tackling things that really are hard.
Given the fact you mention tackling things that really are hard, can you
give a hint about the things you are thinking about.
--
Mark
Re: How to Contribute to River
Posted by Bob Scheifler <Bo...@Sun.COM>.
Rick Moynihan wrote:
> None of this stuff is particularly hard, and I don't mean to be picky,
> as there are clearly ways around some of these issues. My problem is
> only that these things could all be a bit easier.
That's one of the things to wrestle with as we go forward, priority
of making a bit easier things that aren't really particularly hard,
vs tackling things that really are hard.
- Bob
Re: How to Contribute to River
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Rick,
Rick Moynihan wrote:
> None of this stuff is particularly hard, and I don't mean to be picky,
> as there are clearly ways around some of these issues. My problem is
> only that these things could all be a bit easier. If River is going to
> break API's for the repackaging to org.apache, why not also clean up
> these issues through introducing a few interfaces etc?
I see no reason why the introduction of a few interfaces that will be
implemented by SDM e.g. (assuming the signature matches that of the
current methods) in a next release is going to break compatibility. The
preferred way from then on seems to be using interfaces in new API, but
people can continue to use SDM where they did in the past.
There might be a reason why this is not something we want to pursue but
no doubt we will be informed.
--
Mark
Re: How to Contribute to River
Posted by Rick Moynihan <ri...@calicojack.co.uk>.
Mark Brouwer wrote:
> Bob Scheifler wrote:
>> Rick Moynihan wrote:
>>> 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.
>>
>> If the issue is just unit testing, what prevents you from simply writing
>> your own alternate implementations of the classes and linking them in?
>
> I know the question was for Rick, but nevertheless I like to take the
> opportunity to react.
Thanks for this, as your response is largely in line with my views and
experience on the matter. I also seem to have neglected to respond to
this question.
>
> Around the 'expectation' the contract of some important functionality is
> specified as an interface a bunch of tools have been developed, for
> example a product such as EasyMock (for more info read
> http://today.java.net/pub/a/today/2006/06/20/getting-started-with-easymock-2.html,
>
> haven't used it so don't know whether it is handy or not). Also things
> as Google Guice and other DI frameworks most times use in their examples
> interfaces instead of classes that can be extended, resulting in a
> mindset that interfaces is what people expect for DI (note I'm not
> saying this is correct).
I have no experience in using EasyMock or anything along those lines,
instead preferring to create my own mock's where possible. And I can't
say that the experience of wrestling to make mocks out of the Jini
classes was rewarding.
I'm also partial to dependency injection, and find the technique
particularly useful, primarily because it helps to support unit testing.
Again, I've not been using a special DI framework for this.
Instead I have found that Commons Digester can deliver this
functionality, and for me works particularly well:
http://jakarta.apache.org/commons/digester/
> But my main argument against alternate implementations (by extension
> that is), is that you often end up with those nasty constructors that
> require proper arguments which you don't have or don't want to provide
> or that even might fail at construction time. Together with all the
> environmental assumptions that lie in the implementation of the class
> you are extending, also you might drag in a lot of code just because of
> the implementation.
My experience with Jini and mocking is that it can be done, and I did
infact manage to mock out various classes (e.g. the
ServiceDiscoveryManager) for my purposes. Here (as Mark suggests) I
used extension to create my MockServiceDiscoveryManager class. I then
added a few extra methods to allow me to configure different
expected/unexpected behaviors into the implementation.
I must admit that It didn't occur to me that I could have just created
my own implementation of the class in the SDM namespace and linked it in
at runtime. Unfortunately I think this approach is problematic as it is
likely that to get a decent test coverage the developer will want to
actually provide multiple implementations of the mock, i.e. one that
throws RemoteExceptions, one that behaves correctly etc... It seems to
me that the right place to determine which class to use is the test, not
the build script. Developers may also want their mock SDM to be named
in a manner that indicates the mocks behaviour e.g.
RemoteExceptionThrowingServiceDiscoveryManager.
Regarding Dependency Injection, you ideally want to remove knowledge of
the implementation until runtime. Unfortunately with the Jini classes
as they stand this isn't really possible.
Another example I've mentioned before is the partitioning of
responsibilities on LookupDiscoveryManager also makes this awkward
because their is no interface that unifies *ALL* the responsibilities of
the class (other than the class itself).
> Interfaces gives an ultimate freedom and allow for minimal dependencies
> and I don't see why we can't factor out some of the functionality of SDM
> e.g. into an interface, do you Bob?
None of this stuff is particularly hard, and I don't mean to be picky,
as there are clearly ways around some of these issues. My problem is
only that these things could all be a bit easier. If River is going to
break API's for the repackaging to org.apache, why not also clean up
these issues through introducing a few interfaces etc?
If these issues can't be resolved, would it be worthwhile creating
configurable mock implementations of these Jini classes??
--
Rick Moynihan
Software Engineer
Calico Jack LTD
http://www.calicojack.co.uk/
Re: How to Contribute to River
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
> Rick Moynihan wrote:
>> 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.
>
> If the issue is just unit testing, what prevents you from simply writing
> your own alternate implementations of the classes and linking them in?
I know the question was for Rick, but nevertheless I like to take the
opportunity to react.
Around the 'expectation' the contract of some important functionality is
specified as an interface a bunch of tools have been developed, for
example a product such as EasyMock (for more info read
http://today.java.net/pub/a/today/2006/06/20/getting-started-with-easymock-2.html,
haven't used it so don't know whether it is handy or not). Also things
as Google Guice and other DI frameworks most times use in their examples
interfaces instead of classes that can be extended, resulting in a
mindset that interfaces is what people expect for DI (note I'm not
saying this is correct).
But my main argument against alternate implementations (by extension
that is), is that you often end up with those nasty constructors that
require proper arguments which you don't have or don't want to provide
or that even might fail at construction time. Together with all the
environmental assumptions that lie in the implementation of the class
you are extending, also you might drag in a lot of code just because of
the implementation.
Interfaces gives an ultimate freedom and allow for minimal dependencies
and I don't see why we can't factor out some of the functionality of SDM
e.g. into an interface, do you Bob?
--
Mark
Re: How to Contribute to River
Posted by Bob Scheifler <Bo...@Sun.COM>.
Rick Moynihan wrote:
> 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.
If the issue is just unit testing, what prevents you from simply writing
your own alternate implementations of the classes and linking them in?
- Bob
Re: How to Contribute to River
Posted by Vinod Johnson - Sun Microsystems <Th...@Sun.COM>.
>
> 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...
>
In the case of LookupDiscoveryManager, it does implement the
DiscoveryManagement, DiscoveryGroupManagement and
DiscoveryLocatorManagement interfaces
> Also has it been decided yet whether/when River will offer its own
> (Jini)-starter-kit?
>
--
- vinod
Re: How to Contribute to River
Posted by Mark Brouwer <ma...@cheiron.org>.
Rick Moynihan wrote:
> 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.
Rick,
Please create a JIRA issue against River, this allows others to add
their DI pain points too.
With regard to LookupDiscoveryManager I can understand the problem of
those 3 interfaces not being captured by one interface. It is just that
I've never had the need to pass them around in APIs.
--
Mark
Re: How to Contribute to River
Posted by Rick Moynihan <ri...@calicojack.co.uk>.
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/
Re: How to Contribute to River
Posted by Mark Brouwer <ma...@cheiron.org>.
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.
LookupDiscoveryManager I don't know though as that one has most of its
contract already specified by DiscoveryGroupManagement,
DiscoveryLocatorManagement and DiscoveryManagement. Anything missing there?
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 ...
> Also has it been decided yet whether/when River will offer its own
> (Jini)-starter-kit?
This has not been discussed AFAIK.
--
Mark