Re: Recommendations for working with LookupCache

Patrick Wright wrote:

>> BTW was the API for LookupCache not completely clear to you? In case
>> ServiceItem was expected I would have also assumed the
>> LookupCache.discard() method to take a ServiceItem object. Always be
>> extremely cautious when a method takes an object as an argument ;-)
>
> Unfortunately, the API threw me for a bit. I remember asking myself
> some months ago what discard() actually applied to. We hadn't been

I can recall it took me also quite a long time ago what discard
actually did and what eligible for rediscovery really meant. The SDM
specification and code inspection turned out to be the best way to learn
that, see SD.5.5.1 in
http://java.sun.com/products/jini/2.1/doc/specs/html/servicediscutil-spec.html.
It also explains the case that even after discarding a service can
reappear (rediscovery) after a while, the first time we saw this I
thought I was going crazy.

A bit of a problem is that some essential information (the
specifications) is not part of the javadoc, so for the older API you
need to read to read both the separate specifications as well as the
javadoc.

> testing failure scenarios until now so I had never actually tested it.
> You're right about the Object argument. I just assumed that because
> the lookup() always returned a ServiceItem, the cache was based on
> ServiceItems, not service references. Not thinking of equals(), I
> wasn't sure how the LookupCache would perform a reverse lookup in its
> cache (so to speak). I thought the Object argument was possibly there
> to handle some Jini oddity. Oh well!  But in that sense I personally
> find the API for discard() a little out of place compared to the other
> methods in the class.

Now that you mention this, I recall that to be sure about my
interpretation of the SDM specification I looked into the SDM code to
see what was really going on.

You are always welcome to add an Apache River issue in which you state
the spec/javadoc is not clear enough and even suggest improvements of
which you think that it might have saved you valuable time.

Bringing over all the language from the separate specifications to the
Javadoc would also help, although IIRC not everybody agrees with that.

>> [1] this assumes that in case of a specialized proxy a proper equals has
>> been implemented or in case you have a pure Jini ERI proxy (or JRMP
>> stub) this is taken care of automatically.
>
> ...and thanks for reminding me as well to take care of equals().

I forgot to mention hashCode, although that is a consequence of
implementing equals. I would say that in near 100% of the cases the
ServiceID could serve for reference equality, it is also helpful when
your service proxy (in case of a smart proxy) implements
net.jini.id.ReferentUuid, you can have a look at the contributed
services such as Outrigger, Reggie, etc. how they deal with that. As
this would help in getting reference equality when a service is defined
in different class loaders.
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]