[
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 issues.
Regards,
Peter.
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.
Cheers,
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 conventions.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
