On Oct 1, 2009, at 3:44 PM, Patrick Wright wrote:
Hi In order to work around some occasional but troublesome issues where our codebase servers become unavailable or unresponsive, we want to experiment with having our service clients defer to local JARs for loading service interfaces.
Just to be clear, you mean service proxy implementation classes too, the entire contents of the services' -dl.jar files? (Service interfaces used by the client will typically be loaded locally anyway.)
Our current deploy configuration has all clients deploying with the necessary classes anyway, so we feel we can save ourselves the trouble of downloading JARs which won't change between deploys in any case. So--am now trying to figure out how this works. I haven't found an authoritative guide, but what I have so far: - every client should have jsk-platform and jsk-resources JARs in their classpath - every client should have the (otherwise downloaded) service interface classes in their classpath
Again, you mean the service proxy implementation classes too, the - dl.jar files?
From some old mail threads, it seemed that that should be enough, but the service -dl.jars were still being pulled. I've tried adding a PREFERRED.LIST to the first downloadable JAR in the codebase string, using a very broad (package-wide) preferred name expression, but the PreferredClassLoader is still picking them up via a download in the clients. Alternately, it seems that if I could force the codebase for my service to be null, the PreferredClassLoader would look for the classes locally, but I am not sure how to do that--the NonActivatableServiceStarter, for example, doesn't allow a null export codebase.
How about an empty string?
I'm sure I am just one step away from getting the configuration right, and would appreciate some tips.
There are various ways to disable RMI class loading on the client, if that's what you want. One way would be to not set a security manager, if the only reason you had been setting one was because RMI class loader providers require it (i.e. you're not loading untrusted code any other way). Another would be to set an RMIClassLoader provider that ignores codebase annotation values (perhaps just forwarding to the default provider, accessible via RMIClassLoader.getDefaultProviderInstance, but with null codebase values).
-- Peter
