[
https://issues.apache.org/jira/browse/SLING-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209136#comment-14209136
]
Marius Petria commented on SLING-4154:
--------------------------------------
[~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 in the
resource tree. More explicitly use something like
ResourceBasedDistributionComponentFactory to parse a resource tree 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 configure an agent
3. natural way of distributing configs for SLING-3837.
4. no zombie services for publish components as these will not be picked up by
the event handler listening and there will be not OSGI configs installed on
author for them.
5. a natural way of managing authorization when configs are stored in JCR via
ACLs
WDYT? /cc [~tripod]
> 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)
