[
https://issues.apache.org/jira/browse/SLING-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208215#comment-14208215
]
Tommaso Teofili commented on SLING-4154:
----------------------------------------
I think this deserves a little bit of history as the first implementation
started exactly as per Carsten's suggestion but then things changed a bit.
Here's how the configuration of a "push" agent looked like one year ago:
{code}
{
"jcr:primaryType" : "sling:OsgiConfig",
"name" : "publish",
"endpoint" : "http://localhost:4503/system/replication/receive";,
"TransportHandler.target" : "(name=http)",
"ReplicationPackageBuilder.target" : "(name=vlt)",
"ReplicationQueueProvider.target" : "(name=sjh)",
"AuthenticationHandlerFactory.target" : "(name=user)",
"authentication.properties" : ["user=admin","password=admin"],
"ReplicationQueueDistributionStrategy.target" : "(name=single)"
}
{code}
that worked ok and had the big advantage of not requiring any explicit
component wiring, as that was handled by OSGi via DS.
However there were some cons:
1. we could not change an agent configuration in one go, therefore it was hard
to imagine an HTTP API for that doing an atomic update of the agent parameters
(as it would have to eventually change other components settings before
changing the agent)
2. some agents might share a component and therefore changes to that shared
component would be reflected in both agents, even in cases where this is not
wanted (user1 changes shared component for "its" agent1 but he doesn't know he
broke the other agent2 setup doing that).
Another hurdle, which is an implementation detail and can be probably fixed, is
how the JcrInstaller works with OSGi configs, meaning that if it's configured
to store them also in the repository (if available), changing those configs on
the repo would not work reliably (and I don't remember how / why sometimes it
creates another config under /apps ?).
The current approach tries to solve these problems, but I agree (and I think
Marius does too) that the manual wiring thing is error prone.
I would really like to see if we can merge the two approaches and rely on OSGi
for the automatic wiring of components without having to explicitly instantiate
the component objects in our own factory (generic or not).
For the resource based factory I see it as an alternative way of creating
agents, not sure if that's so bad, there may be different reasons for
preferring one way over the other.
I'm fully open for discussions on this and I'd love if we can all sit down
together and look at this stuff together to get the best solution, as I am not
sure it's an easy and quick one.
> 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)
