river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafał Krupiński <rafal.krupin...@sorcersoft.com>
Subject Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Date Thu, 20 Feb 2014 14:50:51 GMT
Dnia 2014-02-20, czw o godzinie 09:08 -0500, Greg Trasuk pisze:
> On Feb 19, 2014, at 11:23 PM, Peter Firmstone <jini@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.

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?


View raw message