On Feb 20, 2014, at 9:50 AM, Rafał Krupiński <rafal.krupin...@sorcersoft.com> wrote:
> > Greg, > from what I understand, River service has now two jars, impl nad dl, > with some classes in the both of them. It gets a little confusing with the infrastructure services like Reggie, because the API classes are already in jsk-lib, so they’re in the local CL. Also, going back to the roots of Jini, when people just set the system property ‘java.rmi.server.codebase’ rather than using a class loader that did codebase annotations correctly, it was a nuisance to call out more than one jar file in the codebase. So, I think that’s why you see the ‘classdepandjar’ approach that was trying to build one single “download” jar. As well, the tradition wasn’t to use multiple project modules - people would want to produce both an ‘api’ jar and a ‘dl’ jar from the same source project, which mandated a tool like ‘classdepandjar’ if you didn’t want to manually track which classes should go into which jar. The “-api.jar”/ “-proxy.jar”/etc convention removes the need to use ‘classdepandjar’, but you still have classes duplicated between the service class path and the published “codebase”. Only now, the duplication is more explicit, in the form of having the same jar appear in the class path and the codebase. Specifically, the service’s class path includes (e.g. for a ‘hello’ service) ‘hello-api.jar’, ‘hello-proxy.jar’ and ‘hello-impl.jar’, whereas the published codebase annotation will include ‘hello-api.jar’ and ‘hello-proxy.jar’, without the implementation jar. > 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. > Regards, > Rafał > Cheers, Greg Trasuk
