Gregg Wonderly wrote:
Wow, I had not chased through all this code. I had assumed that LookupLocatorDiscovery would use LookupLocator.getRegistrar() when in fact it does not, and recreates all the processing itself and uses introspection to reference the getRegistrarMethod for constraints, but otherwise does not call it.
The whole jini package is also what you could call, rather TCP bound. The upper layer of JERI is transport neutral. I saw this as an opportunity to create a firewall traversing jini. But when you look at other subsystems, you will see a direct dependence on Socket, and the assumption that an 'transport endpoint' is identified by a host and port (like the LookupLocator). The strangest thing here, is altough the LookupLocator has this getRegistrar() only the port and host properties are used. LookupLocator is used a _lot_, and to me it seems like it needs to be changed to a more transport neutral implementation.
It is possible to implement a LookupLocator via JERI. Reggie itself exports itself already. The only things we need is an agreed Uuid (configurable ofcourse) and a default for a ServerEndpoint export.
After this we can step-wise improve all the discovery subsystems to use the getRegistrar() method instead of relying on the properties.
A neat thing would also be, a configurable way to silence the existing unicast discovery server already built in Reggie.
Any objections? :-) Gr. Sim -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
