river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Trasuk (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Date Thu, 20 Feb 2014 14:29:22 GMT

    [ https://issues.apache.org/jira/browse/RIVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906997#comment-13906997

Greg Trasuk commented on RIVER-435:

>From the mailing list..

Peter Firmstone
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



Greg Trasuk
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.

So, I would not be in favour of separating out the class loaders in that way.  It adds complexity
and imposes a structure on service authors for no reason.  The only fundamental question that
service writers need to answer now is “should this class be available for download to remote
clients?”  If so, it goes into a jar file that’s in the ‘lib-dl’ folder (that folder
would typically include ‘hello-api.jar’ and ‘hello-proxy.jar’ (assuming the naming
conventions are followed for the ‘hello’ service).  If not, it goes into ‘lib’ (that
folder would contain ‘hello-api.jar’, ‘hello-proxy.jar’ and ‘hello-impl.jar’.

Or perhaps I misunderstand your suggestion…Please elaborate if that’s the case.

I should also note that as currently implemented and written in the proposed spec, the container
_does not_ share the Jini platform libraries (jsk-lib, jsk-platform, etc) between applications.
 Each application class loader includes the Jini libraries separately.  I just couldn’t
think of a case where sharing made very much sense, plus eventually it would make sense to
have separate thread pools per application (1), which would be complicated if the platform
jars were shared.

(1) Each application will have separate threads as it is, but the threads are created inside
the JERI framework, so they’re not under the container’s control, i.e. it’s not possible
for the container to setup prioritization between apps, until the threading system is updated.


Greg Trasuk

> Proposed Standard for Single-Archive Service Deployment Packaging
> -----------------------------------------------------------------
>                 Key: RIVER-435
>                 URL: https://issues.apache.org/jira/browse/RIVER-435
>             Project: River
>          Issue Type: Improvement
>          Components: com_sun_jini_start
>            Reporter: Greg Trasuk
>         Attachments: SingleArchiveServiceDeployment.docx, SingleArchiveServiceDeployment.pdf
> The attached document proposes the layout and general requirements for an archive file
to support simplified "drag-and-drop" deployment for services that adhere to the Service Starter

This message was sent by Atlassian JIRA

View raw message