[ 
https://issues.apache.org/jira/browse/SLING-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208063#comment-14208063
 ] 

Marius Petria commented on SLING-4154:
--------------------------------------

OSGI configs are not powerful enough to express our dependency tree. We ended 
up with configuring agents with a bunch of key value properties using "/" in 
the keys to represent depth (see [1]). Moreover I do not see an easy way to 
have an OSGI config factory in distribution.core that can build/configure 
custom components implemented in a client bundle. Also SLING-3837 is not 
trivial if configs are in OSGI configs, as the place where they are stored is 
unpredictable (i.e. an implementation detail). 

My opinion is that the most flexible way is to use 
ResourceBasedDistributionComponentFactory as the factory to register the 
DistributionComponents as services. We still support some osgi factories that 
can be used to define agents but they are not flexible enough to support all 
usecases in a clean way. I would be happy to talk about all this if you have a 
proposal on how to overcome all these issues.

Assuming that we support resource based (content based) configs we need such a 
component factory.

bq. a) these things need to be renamed as they are not really components to 
make the distinction clear

We need a generic name that means "component" or "part". 

bq. b) there should be a uniform way to create / configure them

The DistributionComponentFactory is exactly that at java level, i.e. it is a 
uniform way (map of properties) to configure core and client components.

bq. c) don't use generic interfaces, use an AgentFactory etc.

Actually the distribution components kinds can be in theory extend by the 
client. A client like CQ can add define a new component interface 
DistributionNotifier and use the same uniform factory to build agents relying 
on notifiers. A client of CQ can then implement such a notifier. In the end we 
can create AgentFactory, ImporterFactory, ExporterFactory, TriggerFactory, 
QueueProviderFactory, QueueDistributionStrategyFactory, 
RequestAuthorizationStrategyFactory, TransportAuthenticatorFactory interfaces, 
but I do not see the practical reason for doing that.

[1] 
https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/sample/src/main/resources/SLING-CONTENT/libs/sling/distribution/install.author/org.apache.sling.distribution.agent.impl.SimpleDistributionAgentFactory-publish-reverse.json
[2] 
https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/component/impl/ResourceBasedDistributionComponentFactory.java


> 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)

Reply via email to