river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: ServiceItem without hashCode/equals
Date Wed, 17 Oct 2012 16:15:24 GMT
It depends on what you are tracking.  I always put my ServiceItems in a map, keyed by ServiceID.
 That map then has values which are maps of LUS to ServiceItem.  I really never use ServiceItem
for anything except a holder of the trio of values, because with multiple LUS on the network,
you really need to hold a reference to all ServiceItems to be ready to deal with transient
LUS behaviors.

ServiceDiscoveryManager does similar things for you.

When you have just a list, the loss of one LUS will cause the disappearance of all services,
instead of possibly none.

You really need more than a list and equals!

Gregg Wonderly

Sent from my iPhone

On Oct 17, 2012, at 10:00 AM, Simon IJskes - QCG <simon@qcg.nl> wrote:

> On 17-10-12 10:31, Peter wrote:
>> Because the service registrar uses serialised form, not objects for comparison with
> If one wants to create a dynamic overview of ServiceItems that are available, in a List,
by attaching a ServiceDiscoveryListener to a lookupCache, and one wants to handle removals
by List.remove(Object), these are processed in the List by equals(), you have to wrap ServiceItem
in a wrapper to to care of the equals(), because the ServiceDiscoveryEvent is making copies.
> So are there reasons for not having an equals() on ServiceItem itself? A quick check
does not reveal any use of equals() in river.
> Gr. SImon

View raw message