[
https://issues.apache.org/jira/browse/SLING-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209136#comment-14209136
]
Marius Petria edited comment on SLING-4154 at 11/13/14 3:07 AM:
----------------------------------------------------------------
[~cziegeler], in the end as I said we can use OSGI configs to start the
services, and that will only require small changes in the current code, i.e.
replace the new ... with configAdmin.createConfig.
However, by doing that we loose the possibility of possibility of configuring
an agent in just one file. We will need around 7 files to configure an agent
through osgi. Also for SLING-3837 it means that we need to have all the publish
components active on author in a disabled state, i.e. that each of them
implements some kind of a disabled state that is checked for each API.
I want to propose a middle ground solution: use OSGI configs for creating the
services as you all suggest but store the actual distribution configs (called
settings) in the resource tree. More explicitly use something like
ResourceBasedDistributionComponentFactory to parse a resource tree with
settings for an agent and create the osgi configs for starting the components.
By doing that I think we can have the best of both worlds:
1. managed way of starting the services via osgi
2. one file to contain all the settings for an agent
3. natural way of distributing settings between instances for SLING-3837.
4. no zombie services for publish components as settings for these will not be
picked up by the event handler and there will be not OSGI configs installed on
author for them.
5. a natural way of managing authorization when settings are stored in JCR via
ACLs
EDIT: 6. have more flexibility in settings representation. We can have
resources that store "template" default settings that are merged into agent
settings before being saved into configAdmin [1]. This allows an application to
keep in one place its application specific default settings.
WDYT? /cc [~tripod]
[1]
https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/sample/src/main/resources/SLING-CONTENT/libs/sling/distribution/jcrsettings/defaults/agents/global.json
was (Author: mpetria):
[~cziegeler], in the end as I said we can use OSGI configs to start the
services, and that will only require small changes in the current code, i.e.
replace the new ... with configAdmin.createConfig.
However, by doing that we loose the possibility of possibility of configuring
an agent in just one file. We will need around 7 files to configure an agent
through osgi. Also for SLING-3837 it means that we need to have all the publish
components active on author in a disabled state, i.e. that each of them
implements some kind of a disabled state that is checked for each API.
I want to propose a middle ground solution: use OSGI configs for creating the
services as you all suggest but store the actual distribution configs (called
settings) in the resource tree. More explicitly use something like
ResourceBasedDistributionComponentFactory to parse a resource tree with
settings for an agent and create the osgi configs for starting the components.
By doing that I think we can have the best of both worlds:
1. managed way of starting the services via osgi
2. one file to contain all the settings for an agent
3. natural way of distributing settings between instances for SLING-3837.
4. no zombie services for publish components as settings for these will not be
picked up by the event handler and there will be not OSGI configs installed on
author for them.
5. a natural way of managing authorization when settings are stored in JCR via
ACLs
EDIT: 6. have more flexibility in settings representation. We can have
resources that store "template" default settings that are merged into agent
settings before being saved into configAdmin [1]. This allows an application to
keep in one place its application specific default settings.
WDYT? /cc [~tripod]
[1]
> Discuss distribution components creation and configuration
> -----------------------------------------------------------
>
> Key: SLING-4154
> URL: https://issues.apache.org/jira/browse/SLING-4154
> Project: Sling
> Issue Type: Task
> Components: Distribution
> Reporter: Marius Petria
> Fix For: Content Distribution 0.2.0
>
>
> Distribution has one main component (agent) and several secondary components
> (triggers, exporters and importers).
> These can be created as java objects using a DistributionComponentFactory.
> The core framework provides a DefaultDistributionComponentFactory that will
> create the components implemented in the core but a client can define its own
> components and factory and the default component factory will use those to
> create a component it does not know of.
> The core framework also provides two ways of registering such a java object
> as an OSGI service:
> 1. using osgi configs, the osgi properties are parsed and passed to the
> factory, a component is created and registered
> (GenericDistributionComponentFactory)
> 2. resource configs, the properties of a resource are parsed and passed to
> the factory, a component is created and registered
> (ResourceBasedDistributionComponentFactory)
> Components registered as OSGI services are available as resources via
> OsgiServicePropertiesResourceProvider.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
