You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Simon IJskes - QCG <si...@qcg.nl> on 2012/10/16 14:34:17 UTC
ServiceItem without hashCode/equals
Anybody any idea why ServiceItem has no hashCode or equals implementation?
Gr. Simon
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: ServiceItem without hashCode/equals
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 17-10-12 18:15, Gregg Wonderly wrote:
> 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.
I was expecting a somewhat pre-cooked solution from SDM, the
datastructure you describe looks similar to SDMs internal structure.
> 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!
You are right. Presenting this data not only involves rendering in the
sense of which and how Entries are presented, but also reductions of
multiple SI into 1 line to present to the user.
Re: ServiceItem without hashCode/equals
Posted by Gregg Wonderly <gr...@wonderly.org>.
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 <si...@qcg.nl> wrote:
> On 17-10-12 10:31, Peter wrote:
>> Because the service registrar uses serialised form, not objects for comparison with ServiceTemplate.
>
> 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
>
Re: ServiceItem without hashCode/equals
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 17-10-12 17:00, Simon IJskes - QCG wrote:
> On 17-10-12 10:31, Peter wrote:
>> Because the service registrar uses serialised form, not objects for
>> comparison with ServiceTemplate.
> So are there reasons for not having an equals() on ServiceItem itself? A
Isn't the identity of the ServiceItem: SvcProxy,ServiceID ? The equals
of a SvcProxy is kept on the calling side, because of the check the
BasicInvocationHandler.
I don't want to change serviceitem, but i'm interested in the underlying
principle.
Re: ServiceItem without hashCode/equals
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 17-10-12 10:31, Peter wrote:
> Because the service registrar uses serialised form, not objects for comparison with ServiceTemplate.
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
Re: ServiceItem without hashCode/equals
Posted by Peter <ji...@zeus.net.au>.
Because the service registrar uses serialised form, not objects for comparison with ServiceTemplate.
This of course has been a complaint for developers who wanted to do more complex comparisons, but doing so would require deserialising into object form.
StreamServiceRegistrar, although it has no service implementation, was intended to handle more complex comparison based logical queries locally. The api of this registrar extension interface was developed collaboratively on river dev, we just need a service implementation if someone is willing and has the time to take up the challenge.
Cheers,
Peter.
----- Original message -----
> Anybody any idea why ServiceItem has no hashCode or equals implementation?
>
> Gr. Simon
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397