river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Tue, 28 Jul 2009 21:00:45 GMT
Gregg Wonderly wrote:
> Exposing those details in a 
> way that doesn't cause "downloading" or "unmarshalling" (which can lead 
> to codebase contamination because of local class uses) is what is left 
> to do.

There are updates visible at http://reef.dev.java.net which change the
MarshalledDataAccess interface to include

	public Map<String,Object> getFieldValues();

There is also work that happens in MarshalledInstance (for the service) and 
EntryRep (for attributes) to make them create this map as the objects are 

Thus if you wrote code such as

	public void discovered( ServiceRegistrar regs[] ) {
		for( ServiceRegistar reg: regs ) {
			if( reg instanceof ServiceLookup ) {
				doLookup( (ServiceLookup)reg );
			} else {
				... normal ServiceRegistrar

	private void doLookup( ServiceLookup lu ) {
		RemoteIterator<ServiceEntry> it =
			lu.lookup( template, Integer.MAX_VALUE );

you could look at both ServiceDataAccess for the service proxy and each of the 
Entry objects to see the public, native valued fields names and values via 

If you've never looked at reef, go to the 'Documents and files' link on 
http://reef.dev.java.net and download the api docs and look at them.  The 
reef.jar and reef-dl.jar files are there too, and you can swap out reggie.jar 
and reggie-dl.jar in our jini deployment to make use of this lookup server.

Again, it is backward compatible with any existing use of reggie (to the best of 
my ability to determine that compatibility) because it provides a 
ServiceRegistrar implementation.  But, it adds to the proxy, the implementation 
of the ServiceLookup interface so that you can look for that to be implemented 
by ServiceRegistrar, and take advantage of the extra features.

I started on a ServiceDiscoveryManager like replacement that would hide the 
differences of the two lookup services and provide new features that only 
ServiceLookup would provide the "fast, no downloads" capabilities, but existing 
ServiceRegistrars would cause downloads and not be as scaleable.

Still haven't found time to finish that, but if there is real interest in this, 
than I might be more motivated.

Gregg Wonderly

View raw message