Wade Chandler wrote:
Heh heh, yes, there needs to be a way to inspect the service, some credentials,
without unmarshalling. A way to ask for all services out there, the class or
interface they implement, along with other user identification information such
as a displayable name, description, version, etc I would think. What about this
list? Anyone have a link to an archive? I want to find your other email Gregg
and see what you wrote about there.
I was just in my list of things I still wanted to put back into River. I did
this about 2-3 years ago, and have been using it since then. The Reggie
architecture makes it easy to do. I want it to be an optional interface
supported by lookup services.
As an example, the current definition of lookup(ServiceTemplate,int) in the
Reggie proxy is shown here.
// Inherit javadoc
public ServiceMatches lookup(ServiceTemplate tmpl, int maxMatches)
throws RemoteException
{
return server.lookup(new Template(tmpl), maxMatches).get();
}
If you look closely, you will see the "get()" on the end of the line, above,
which does the unmarshalling. So, just before it gives you the results, they
are unmarshalled.
The following method is one of the ones that I added which is in the
ServiceLookup interface API.
public RemoteIterator<ServiceEntry> lookupEntries( ServiceTemplate tmpl,
int maxMatches ) throws RemoteException {
return new LocalEntryIterator( server.lookup(new Template(tmpl),
maxMatches ) );
}
So, it's possible for Reggie to have a simple conversion done to provide this
capability. However, I don't think it's realistic to ask that all
ServiceRegistrar instances support this as the Primary mechanism.
What I've done so far, works. Are the names and relationships exactly what I'd
want to see in a production system? Perhaps not. Below is an example usage of
the API.
If you had a ServiceRegistrar instance which also implemented ServiceLookup,
you'd do something like the following to perform a lookup and get a name for all
the service instances and add them to a list via addService().
// make sure no downloading occurs to resolve these classes
ClassLoading.neverPrefer( Name.class );
ClassLoading.neverPrefer( ServiceInfo.class );
ServiceTemplate tmpl = ...
ServiceRegistrar reg = ...
if( reg instanceof ServiceLookup ) {
ServiceLookup lu = (ServiceLookup)reg;
RemoteIterator<ServiceEntry> ents = lu.lookupEntries( tmpl );
for( ServiceEntry ent : ents ) {
Set<ServiceDataAccess<Entry>> accs =
ent.getMarshalledAttributeSets();
String name = null;
for( ServiceDataAccess<Entry> entacc : accs ) {
if( entacc.getDataClassNames().
contains(Name.class.getName() ) {
// Will resolve to local VM class
name = ((Name)entacc.getData()).getName();
// Prefer Name, but allow ServiceInfo
} else if( entacc.getDataClassNames().
contains(ServiceInfo.class.getName() &&
name == null ) {
// Will resolve to local VM class
name = ((ServiceInfo)
entacc.getData()).getName();
}
}
if( name == null )
name = ...find a name from classes...
addService( name, ent );
}
} else {
// you can do regular lookup here and get live objects, or
// you can ignore all instances that don't support
// access to the marhalled results.
}
So in this case, only the Entry values for a Name instance of a ServiceInfo
instance will ever be instantiated. My changes to ClassLoading, to provide the
ability to short circuit PreferredClassLoader from downloading the first jar in
the codebase to find the PREFERRED.LIST to see how to resolve the classes being
unmarshalled, keep unneeded code from being unmarshalled. Imagine what would
happen to your VM where 200 developers are working on the same project, all
running netbeans, and using a service proxy that unmarshalls into a 1MB class
instance. Suddenly, you do a lookup and 200MB goes aways!
Nicalas, and others desires to have a no-network environment could help deal
with some of the issues of rogue code. At some point, you will want to not have
all of the services running on your computer when you are testing a client. You
might in fact not be able to run the server on your computer. Both network and
non-network environments are interesting to explore. My investigation into
these issues and how to get away from downloading anything, until you use it,
has been very revealing of the issues to me.
Gregg Wonderly
