thanks for your comments Tobias.
way to little documentation (javadoc, general architecture)
yes, while I have some doc written in a README.md, javadoc needs to be improved.
Don't use HTTP headers to transport additional information. this makes it harder to get request correctly though proxies and firewalls ... If you use customer HTTP headers, it's best practice to prepend an app specific prefix, eg: X-Sling-Replication-Action
good points, then trying to get rid of the headers at all sounds like the best option
why do you expose a ReplicationConfigurationServlet and not rely on default mechanisms to update config, e.g. update the config via SlingPostServlet or via felix console? (Is there some functionality missing in Sling or does every component needs to provide it's own management REST API?)
it's not something missing, I'd like to provide an HTTP/REST API for working with agents, that including triggering replication, checking/updating configuration, checking queues (TBD), creating/deleting agent (TBD).
If there's a smarter way of doing such things you may think of just let me know.
Current HTTP API has:
HTTP POST (/w parameters) to http://host:port/system/replication/agents for triggering replication of all existing agents
HTTP POST (/w parameters) to http://host:port/system/replication/agent/foo for triggering replication of agent foo
HTTP GET http://host:port/system/replication/agent/configuration/foo for retrieving configuration of agent foo
HTTP POST (/w parameters) to http://host:port/system/replication/agent/configuration/foo for updating configuration of agent foo
I would reconsider if Activate and Deactivate really are good names.
sure, I agree "add" and "delete" sound more appropriate.
btw: how is deactivate implemented? not via an empty content package?
an empty package (see VoidReplicationPackage)
I don't know if TriggerPathReplicationRule is really a sufficient filter. Usually it's hard to determined at what point a modified subtree is ready to replicate. you would probably need to add much more logic to it
right, that's hard to do in general if e.g. create operations are not "atomic" (create /a/b, persist, create /a/b/c persist, create /a/b/c/d etc.) so depending on the use case something like collecting "bunch" of changes may work better; however that's good you raised the point as that will need to be handled properly.
I don't quite understand AuthenticationHandler. Are those providers that are used to add authentication to the HTTP requests, or are they consumers that are used to authenticate replication payloads?
it's the former, but it's not just for HTTP, they're used for authenticate TransportHandlers which may deliver content to either an HTTP endpoint (most often) or not (e.g. file system, or other)
the adapter from SlingRequest to ReplicationPackage is really questionable in IMO. It is used in a very specific case and the adaption is considerably expensive. Or do you foresee that other clients of this API adapt a request to a ReplicationPackage ?
I agree that can be much improved, that's just used from the receiving servlet for reading a replication package stream to install the package on the receiving instance.
suggest to add package-info.java files with the bundle export information over <Export-Package> elements in the pom.xml
while collecting other feedback (if any) I'll work on the topics brought by Tobias.