On Feb 20, 2014, at 11:31 AM, Rafał Krupiński <rafal.krupin...@sorcersoft.com> wrote:
> Dnia 2014-02-20, czw o godzinie 11:02 -0500, Greg Trasuk pisze: >> On Feb 20, 2014, at 9:50 AM, Rafał Krupiński >> <rafal.krupin...@sorcersoft.com> wrote: >> > (...) >>> That's why we need PreferredCL, >>> to ensure that these classes are loaded from the right jar. >>> I thought employing the api/impl/proxy would make PreferredCL obsolete, >>> wouldn't it? >>> >> >> I don’t think so. PreferredClassLoader does two things - >> >> 1 - It isolates the service proxy from the client’s classes >> 2 - It helps reduce the “lost codebase” problem by making sure that classes >> used only by the proxy aren’t loaded from the local CL. > > Correct me if I'm wrong, but PreferredCL decides on which jar to use > based on jar's metadata - PREFERRED.LIST. If you have two identical > jars, one local and one remote, there's no way to decide which to load. > On the client side, the “-proxy” jar should never be in the local class path. Preferred CL mainly applies to third-party libraries that might be used by the proxy, but aren’t accessed by the client itself. You’re right, that the applicability is limited in most cases. > But I'm not sure if there is a need anymore, as API classes used by the > client must be in the export codebase anyway. Incoming proxy will we > deserialized using it's codebase but it must use interface loaded from > local CL in order to be assignable to a reference. > That’s right - the “-api” classes need to be in the client’s local class path (assuming the client is in Java). In fact, the client doesn’t really need them in the codebase annotation, and won’t generally download them remotely. It’s actually only the service browser that fails if the “-api.jar” isn’t in the codebase. I suppose it could also be a problem if you were using a dynamic language (Groovy maybe?, Jython, Javascript, etc) on the client side that didn’t actually need “-api.jar”. > Regards, > Rafał > > Cheers, Greg.
