[
https://issues.apache.org/jira/browse/RIVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13907079#comment-13907079
]
Greg Trasuk commented on RIVER-435:
-----------------------------------
> Why the properties file? Seems as if this would be service specific, and I'm
> not sure what could not be put into a service' configuration.
Yes, it is service-specific. The properties file is there to identify (1) the
name of the service class to instantiate, and (2) provide the arguments to the
service's constructor (generally just the name of the configuration file, but
could be more). You might want to edit this, for instance, to select whether
you want a TransientOutriggerImpl or a PersistentOutriggerImpl. That
information (under the ServiceStarter conventions anyway) is required before
the configuration gets read. Basically, the 'start.properties' file
corresponds to what would have been in the ServiceStarter configuration, rather
than the service's configuration.
>A service's configuration may be the .config or it could be .groovy (or other
>language) as long as it provides net.jini.config.Configuration right? Would a
>container need to know what the configuration requires (loadable by
>ConfigurationProvider)
Good question - I think we have to assume that a container will need to use its
own Configuration impl in order to read the config out of the SAR rather than
the file system. In River-Container as it stands, the
VirtualFileSystemConfiguration reads the file, and delegates the task of
processing it to a ConfigurationFile instance. So that implementation doesn't
support Groovy-based config (it's based on the stable release branch, which I
don't think has GroovyConfig in it). I suspect the container does need to know
what the config language is. We could have another property in
'start.properties' to identify the config language. It might also be possible
to use the current 'META-INF/services/net.jini.config.Configuration' mechanism.
I'm not sure which would be better.
>Do we need some manifest entries to define version of the SAR, any other
>meta-data?
Possibly. I suppose manifest entries could replace the 'start.properties'
file. I think my though process was that getting a customized manifest into
the SAR would require just a little more ritual incantation (in Maven anyway)
than a plain file in the archive's root. I also had in the back of my mind,
the possibility of passing in an unpacked directory to the deployer, rather
than a SAR.
> 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)
