Mark Brouwer wrote:
It seems you want to prevent from downloading JAR files that is driven
by the codebase annotation (the codebase annotation contains the encoded
PREFERRED.LIST [1]). I believe you want to prevent from downloading JAR
files due to limited bandwidth you have over WAN connections.
I want to have 100 services visible to a client, and discovery to not cause any
codebase references and thus force downloading because of PREFERRED.LIST inquiries.
You have to consider that I also have my reef project changes to Reggie active
too. Thus, I can select when the service or any Entry values are deserialized.
My service registrations include Entry values such as service names, icons,
javax.help files (referenced by URLs) etc. I want to be able to display to the
user, icons for all visible services without unmarshalling anything except the
bare minimum which is needed to show the user icons and names.
To me it looks like you want the client to be the discriminator whether
classes (and thus the download JAR file) should be downloaded and not
the server through the PREFERRED.LIST it provides in the codebase
annotation, why do you want to turn that around?
I have a known platform that my services adhere to. That platform is expressed
in the PREFERRED.LIST explicitly, but is also expressed in the jar content and
the classloader behavior implicitly. I want the platform that the service is
asserting to be conveyed to the client as part of the service registration, not
as part of the services codebase content. This would allow the client to decide
whether or not it could be compatible with that platform, early on.
[1] I guess the codebase annotation is getting rather large that way
(although RFC 2616 doesn't seem to place any a priori limit on the
length of a URI you might run into problems in reality due to this) and
I think the various marshalled streams don't optimize on recurring URIs
(no URI table I can detect for classes with the same annotation) so you
will be consuming additional bandwidth (a lot?).
What I would say is that it's not part of the URL, but rather part of the
structure of the annotation string, which would break compatiblity with
arbitrary RMI applications when using the JRMP exporter. I.e. you might imagine
the following (incomplete) code used to compose the annotation.
public String getAnnotation() {
String[]urls = codebase.split(" ");
URL u = new URL( urls[0] );
URLClassLoader ld = new URLClassLoader( new URL[]{ u } );
URL ru = ld.getResource( "META-INF/PREFERRED.LIST" );
URLConnection uc = ru.openConnection();
DataInputStream ds = new DataInputStream( uc.openConnection() );
try {
byte[]data = new byte[uc.getContentLength()];
ds.readFully( data );
return codebase+"\n"+new String(data);
} finally {
ds.close();
}
}
The PREFERRED.LIST content would thus create a multi-line string of the form
http://some.code.base/file1.jar http://some.code.base/file2.jar
PreferredResources-Version: 1.0
Preferred: false
This, is just my initial thought of a trivial to implement solution for getting
the information into the codebase string. It might be more compatible to use
return codebase+" pref:/"+URLCoder.encode( new String(data) );
to make the additional information be recognizable for what it is.
The PreferredClassLoader would be changed to look at the annotation for the
defined separator ('\n' or " pref:/" or whatever) and use that PREFERRED.LIST
content instead of downloading one or more jars and extracting it.
Gregg Wonderly
