[
https://issues.apache.org/jira/browse/SLING-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896606#comment-13896606
]
Marius Petria edited comment on SLING-3385 at 2/10/14 2:40 PM:
---------------------------------------------------------------
Hi Felix,
You are right, that would probably be a nicer design, however there are some
issues with it.
1. We want to be able to replicate to multiple agents at once so that would be
done by posting to /agents with multiple X-replication-agent headers.
2. There seems to be no consensus on how to expose such an hierarchy via HTTP
(see \[1\]). I am trying to propose here a not so nice compromise.
More specifically exposing /system/replication/agents/\{agentName\} can be done
with a ResourceProvider or with a hierarchy of shadow nodes. While for agent
configuration the shadow nodes make some sense because they contain properties
of the configuration and they can be accessed via standard servlets (in
/etc/replication) for agent and queue actions/status a shadow hierarchy of
nodes will be very unnatural.
Basically the compromise solution is to create only the root node of the
hierarchy and use query params to filter the results.
[1] https://issues.apache.org/jira/browse/SLING-3352
was (Author: mpetria):
Hi Felix,
You are right, that would probably be a nicer design, however there are some
issues with it.
1. We want to be able to replicate to multiple agents at once so that would be
done by posting to /agents with multiple X-replication-agent headers.
2. There seems to be no consensus on how to expose such an hierarchy via HTTP
(see [1]). I am trying to propose here a not so nice compromise.
More specifically exposing /system/replication/agents/{agentName} can be done
with a ResourceProvider or with a hierarchy of shadow nodes. While for agent
configuration the shadow nodes make some sense because they contain properties
of the configuration and they can be accessed via standard servlets (in
/etc/replication) for agent and queue actions/status a shadow hierarchy of
nodes will be very unnatural.
Basically the compromise solution is to create only the root node of the
hierarchy and use query params to filter the results.
[1] https://issues.apache.org/jira/browse/SLING-3352
> Expose replication agents actions and information via HTTP.
> -------------------------------------------------------------
>
> Key: SLING-3385
> URL: https://issues.apache.org/jira/browse/SLING-3385
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Reporter: Marius Petria
> Labels: replication
>
> We need a safe way to expose replication agents actions via HTTP.
> Replication agents are OSGI services that can do the following actions:
> - replicate a content tree (build a content package and add it to a queue)
> - add a content package into a queue
> - remove a content package from its queue
> A replication agent also exposes information about packages in its queues.
> We have to expose all this actions and information over HTTP in order to be
> available to authorized users.
> Actions:
> - Replicate (schedules a replication action)
> POST /system/replication/agents
> X-replication-action: ADD/DELETE
> X-replication-path: /content/mycontent
> X-replication-agent: {agentName}
> - Import/Export (adds or removes a package from a queue)
> POST /system/replication/packages
> X-replication-action: PACKAGE_OFFER/PACKAGE_POLL
> X-replication-queue: {queueName}
> X-replication-agent: {agentName}
> -Information about agents, queues, packages
> GET /system/replication/agents?agent={agentName}
> GET /system/replication/queues?agent={agentName}
> GET /system/replication/packages?queue={queueName}&agent={agentName}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
