Hi Vinod, Took me some to respond because I had to do some homework ... and some experiments.
There are 2 questions at the bottom for those who want to skip a lot of explanation and history. Vinod Johnson - Sun Microsystems wrote:
I must be missing something here, but do you see any exception from the SDM, or is the event silently dropped? In the case of reggie, its proxy
It is silently dropped when the source in the registration doesn't match the source in the event. Based on the inline comments I believe the author considered it a case where the event arrived before the eventReg is in the map.
implements equals (which the SDM uses to check for equality) to do a comparison on the net.jini.id.Uuid value returned from getReferentUuid. Is it that your registrar proxy does not do the same? Given the
As if you kissed me awake :-) The very short answer to this is that I removed ReferentUuid from the specialized proxy as ReferentUuid in Reggie was IIRC only used by its own equals and then (4 years ago) I didn't understood the implications of its usage to the extend I apparently should have and there were some questions whether in my case it was the right thing to do (i.e. utilizing ReferentUuid). The equals for my ServiceRegistrar is specified by the JSC Specification which states it implements reference equality by default but doesn't make usage of ReferentUuid, it is implemented as an implementation detail as part of the invocation handler of the dynamic proxy that is placed for the specialized proxy and that means for being equal the other proxy should be defined in the same class loader, which becomes painfully clear is brittle in some occasions. In 2003 John McClain gave me a course "proxy equals" for which he should have flunked me then ;-), see http://archives.java.sun.com/cgi-bin/wa?A2=ind0307&L=jini-users&F=&S=&P=14022 . The thread ended with me saying "Whether the container generated dynamic proxy implements ReferentUuid depends on whether the JSC service proxy implements ReferentUuid. I thought of having the container generated proxy always implementing ReferentUuid during the conversion of some of the contributed services, but I leave that for when I have time to think over the consequences." 4 years passed by and I didn't gave it any thoughts because I forgot about it and never ran into any problems, well I'll had to do that thinking now.
specification of ReferentUuid, it's probably better to actually compare the Uuids rather than test for equals - I can't answer the history/rationale behind the current state of the implementation.
John McClain once said: "ReferentUuid is currently intend more as a tool that people can use to implement robust and stable notions of reference equality, than as an interface that clients will use directly. I agree it can do more, and the spec has been written so it can (and some day may), in particular clients can infer reference equality if two proxies that implement ReferentUuid have the same Uuid - but for Davis we were not comfortable with forcing all proxies to implement ReferentUuid". I think I've read that as that there is still a grand master plan for ReferentUuid and to make it more explicit as part of certain specs. For example requiring a Lease to implement ReferentUuid would appeal to me more than relying on its equals. Also I think I feel very uncomfortable with e.g. an ServiceRegistrar and its administration proxy being equal because they rely on ReferentUuid for that purpose. Both are fundamentally different although their equals imply they are the same. I believe defining reference equality through equals is just not the best way, but it is a fact for some of the specifications. If for a proxy it boils down to implementing ReferentUuid and the only usage is for its equals implementation to utilize it I wonder why we don't make clients aware of it and have them perform the reference equality check. Modify the future specs to demand Jini service proxies to implement ReferentUuid, if not overridden by another spec. But for now I just modified the container generated dynamic proxy code to make usage of ReferentUuid and see what the implications would be for the container implementation and for the JSC Specification: 1) if a specialized proxy handed to the container doesn't implement ReferentUuid the container will add ReferentUuid to the dynamic proxy and provide its own reference equality when invoked; 2) if the specialized proxy implements ReferentUuid the invocation handler of the dynamic proxy will delegate to the specialized proxy to provide the answer for getReferentUuid() 3) if the specialized proxy doesn't override Object.equals ReferentUuid will be utilized for equals, otherwise the equals on the specialized proxy will be utilized 4) a similar mechanism for the administration proxy returned by a specialized proxy that is also enhanced by the container to get all kinds of free administration functionality. The current equals implementation will verify by a way that is not subject to class loader skew whether one is main proxy and the other the administration proxy as I don't think these should be considered true (Reggie e.g. considers them equal). Rerunning the tests without modification of any of the services seems to indicate everything works just fine and the source for the event registration and events itself are considered equal. I like to takes John McClain graduate course now, so some more questions: 1) Going through the source of the contributed services to see which other proxies provided by Seven should take advantage of ReferentUuid I noticed that for Reggie the decision was made to have com.sun.jini.reggie.Registration implement ReferentUuid, while for the other type of registrations (events) it was decided that they don't implement ReferentUuid, what is the rationale behind that decision? 2) Why don't the equals implementation at least check whether the object passed in for the test of equality implements the same interface. So a Lease.equals(Object) should test whether object is of type Lease, etc, same for transaction participant, etc. I'm aware the chance of 2 Uuids clashing is rather small (of not done on purpose), though it seems 'more correct' to test for having 2 object that implement also the primary interface? -- Mark
