I had that same thought as I read Dennis' message. It makes a lot of sense. The service interface should stay as constant as possible while the proxy should be as free as possible to change.
My approach to -dl.jar caching was vaguely similar to the httpmd idea. My services all have embedded http servers which scan their codebase folders at launch and construct urls with SHA-1 hashes prepended (it computes the SHA-1 at runtime). Then in my RMIClassLoaderSPI.createClassLoader(), I use my own jar: protocol handler that recognizes the SHA-1 in the URL and looks in its local cache for a file with the same hash. If present, it uses the local copy and skips the download. If absent, it downloads and caches the jar, with the SHA-1 as the cache key. If the URL does not have a hash or if the downloaded jar does not match its advertised hash, then I fall back to the normal jar loading behavior. I like this approach because it's backward compatible to clients and services that don't know about the hash-in-url convention -- they just fall back to downloading the jar every time. Chris -----Original Message----- From: Peter Firmstone [mailto:[email protected]] Sent: Thursday, May 20, 2010 2:24 AM To: [email protected] Subject: Re: Codebase service? I like & get what your saying, I'd like to add something too. Can we separate the Service Interface from the Smart Proxy? So they're in separate artefacts /downloadable jar's?
