[
https://issues.apache.org/jira/browse/RIVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13907060#comment-13907060
]
Greg Trasuk commented on RIVER-435:
-----------------------------------
> One use case for sharing jsk-lib would be to provide for pooling of discovery
> management resources.
True, but don't you then get into needing a proper "shared area" with shared
configuration to manage it? I think you're right that it's
implementation-specific. FWIW, this could be done in River-container, but I
didn't see the need to implement it (so far). The mechanism would be similar
to the way "special" values are injected now. Works like this:
Consider how the discovery group is set for all applications container-wide:
1 - The container itself has shared context, but it isn't normally handed to
the applications. All the components to it are put together and wired via
dependency injection. There can also be global properties set into this
context.
2 - Preparing the applications (setting up classpath, security, etc) is handled
by a "Deployer" module, e.g. 'StarterServiceDeployer'
3 - That module has a config file that specifies what classloader to use as the
parent, what properties to grant to applications, what platform jars to
include, etc. It also has a "configuration" section that looks like this:
<code>
configuration {
// Anything on the left-hand side of '=' is set into the application config
// as a "special variable, accessible through '$name'.
discoveryGroup=defaultDiscoveryGroup;
// For privileged deployer, include
// context=context;
}
</code>
4 - The container provides a ConfigurationProvider
(VirtualFileSystemConfiguration) that knows how to read the config file from
inside the SAR. The deployer module sets the values in (3) into this
VirtualFileSystemConfiguration, so that they appear as "special entries" as
defined in ConfigurationFile. So for instance the 'discoveryGroup' string
property that is set at the container level is available (using the above
config) in the service's 'reggie.conf' as '$discoveryGroup'.
So, the end result is that the service can use the globally-set
'defaultDiscoveryGroup' value when setting up it discovery, so we don't have to
go edit the config for every service (although the service could use a
different setup if it wanted to).
If shared discovery management turns out to be a compelling feature, it can be
implemented by adding another container module that sets it up, stores the
discovery manager in the global context, and then the deployer config file
would call that out as a "special entry".
> 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)
