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. 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. Regards, Rafał
