[
https://issues.apache.org/jira/browse/RIVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908538#comment-13908538
]
Greg Trasuk commented on RIVER-435:
-----------------------------------
OK, I think I see what you’re getting at. The class loader hierarchy would
look like this:
System ClassLoader ---------- API Loader ---- - Application Classloader
....................................................... +
....................................................... + ------------ Proxy
Classloader (one for each proxy)
(not sure how well the ASCII-art will come out. Proxy Classloader is a child
of the API loader, so is Application ClassLoader)
To implement that, (1) the container has to create the loader hierarchy and
pass the class loaders into the ConfigurationProvider, (2) the service’s
configuration has to call out the API class loader in the constructor for
BasicILFactory.
I’m normally reluctant to add extra complexity if we can avoid it, but I think
the add’l layer is minimal. In river-container that won’t be too hard to
setup, but I wonder if it should be flagged as an optional feature in the spec
(the spec would then need is to specify a ‘lib-api’ folder as well, and also
specify the special-entry names for the class loaders) so as to make a simpler
implementation possible.
> 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)
