Gregg Wonderly wrote:
Another enhancement I have been wanting to do is to make the RMIClassLoaderSPI string include the PREFERRED.LIST content. The encoding would be a bit tricky, depending on how much compatibility you want to maintain. I currently have a static method (with a permission check) in ClassLoading, called neverPrefer(String) which I use to set the "platform" that I am want to assert for my application. Anything that is "never preferred" will never force downloading of the codebase. It works, but is really a back door into the logic which could be driven with real data from the services preferences.
Hi Gregg, I think I need a bit of help to understand the above completely and therefore my remarks below might be completely irrelevant, nevertheless. 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. 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? Without knowing whether I did understand you I'll stop for now. [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?). -- Mark
