Dnia 2014-02-20, czw o godzinie 09:08 -0500, Greg Trasuk pisze: > On Feb 19, 2014, at 11:23 PM, Peter Firmstone <j...@zeus.net.au> wrote: > > > You could adopt the directory conventions api, impl and proxy, instead of > > lib and lib-dl? That way you could make sure the api is loaded into the > > application class loader, while the implementation can be loaded into a > > child ClassLoader for maximum cooperation (in case the service > > implementation also uses other remote services) while avoiding name space > > visibility issues. > > > > I’m not sure what that would accomplish. As it stands now, the application > has one class loader which is effectively a child of the system class loader. > If the app is going to act as a consumer, it will unmarshall the service > provider’s proxy in the usual way, which will end up with a > PreferredClassLoader that is a child of the application’s class loader > (standard Jini stuff - nothing to do with the container), so proxies from > other providers are effectively in different class loaders. What would be > the advantage of separating the API classes from the implementation classes? > It’s only the lib-dl jars that are available to outsiders, so there’s no > chance of leaking the implementation classes to consumers, assuming the jars > files are created correctly, which is the service author’s responsibility.
Greg, from what I understand, River service has now two jars, impl nad dl, with some classes in the both of them. 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? Regards, Rafał
