Already asked recently as part of a footnote, but there it got no response, so I'll give it another try.
Equality for services, leases, event registrations, etc. is still a painful exercise (especially in long running systems in which codebases might change due to rolling fixes into services) and a case [1] for which I must come to the conclusion I can't seem to create a proper work around that makes a requirement work with a generic lookup service. From the Davis project I know that ReferentUuid http://java.sun.com/products/jini/2.1/doc/api/net/jini/id/ReferentUuid.html was designed to help in this area, given the fact since then none of the classes that could take advantage of it have been made aware of it and none of the Jini Specifications got any language that indicates ReferentUuid plays a role here. I'm curious to find out whether people think this is something that should be tackled? [1] probably my explanation is not detailed enough to follow all that is going on, but the following is the case I try to solve and the problem analysis why it doesn't work. Assume a Jini service that is defined in class loader A creates a child class loader B for deploying a algorithm plugin or a web application. The Jini service is responsible for finding a lookup service on the network. During the unmarshalling of the lookup service a new class loader C is created that has as its parent class loader A. Assume this class loader is passed on the plugin that is defined in class loader B, all operations in the plugin take place with a context class loader that equals B. From within the plugin it registers for receiving events through the Jini Distributed Event Model for which it will get an EventRegistration that contains a source field. The ServiceTemplate contains types that are only available in class loader B. The registration is done indirectly through a SDM. The lookup service finds a match and notifies the exported remote event listener. The event is unmarshalled with a context class loader of B and a default class loader of B, this will result in the creation of a class loader D that has B as its parent. The service item part of the event is usable in the context of the plugin but in this case the SDM rejects the event because it turns out the source of the registration and the field doesn't match. Analysis learns that the source of the registration is defined in class loader C and the source as part of the event in class loader D. The cause of this is the default class loader used during unmarshalling which is different from the perspective of the BasicInvocationDispatcher (receiving events) and the BasicInvocationHandler (event registration) as the basic invocation handler uses the class loader of the proxy (C) as the default loader. Class loader hierarchy A------- | | | | | C (proxy lookup service, event registration, source) | | B------- | | | D (service events, source) I have 2 workarounds to my avail that I have working: 1) the first one is to utilize the inverted event model on ServiceRegistrarX which results in the unmarshalling of events that carry a source field that is defined in the same class loader as the source field of the event registration, i.e. the source field will be defined in class loader C as that is the default loader during unmarshalling. 2) use the Jini Distributed Event Model and have as the source an object that is part of the Platform (class visible from both class loaders) such as a Uuid. Well that is my preferred choice anyway (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6316548) but due to compatibility concerns it ain't the default for the lookup service I provide. The problem with the above is that both are not supported by the majority of lookup services in the field deployed and as such is a lame solution. In case the source object would have implemented ReferentUuid the various utility classes could have utilized that and it would have worked, the same problem I foresee with ServerTransaction, etc. To be really honest it is kind of problematic if it turns out all Jini related operations should originate from one big happy class loader as that rules out a lot of possibilities in the design of Jini services. -- Mark
